From nobody Tue Mar 1 02:17:26 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B851B3E80; Tue, 1 Mar 2016 02:17:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160301101723.4415.77699.idtracker@ietfa.amsl.com> Date: Tue, 01 Mar 2016 02:17:23 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:17:24 -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 of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-04.txt Pages : 27 Date : 2016-03-01 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-04 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 Tue Mar 1 02:18:27 2016 Return-Path: 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 8DBF71B3E88 for ; Tue, 1 Mar 2016 02:18:25 -0800 (PST) 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 S82ubSBYaypY for ; Tue, 1 Mar 2016 02:18:23 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C371B3E85 for ; Tue, 1 Mar 2016 02:18:22 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n186so28926877wmn.1 for ; Tue, 01 Mar 2016 02:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=pW4K4AvzBHmxkbEdfM4KnnSmyTZcN+7Bx7ziinqgc7U=; b=gGW4mfGnkX4RB/XwDNCsOAsKOf/hS+PLMPob0NFZEwX1cbYutdIFBqzGOrnAM3X0rI PExkyWmXKw2N7TzuwLCg/LYZJSpD1vo+CUqJsTmLrYZ+MBCko0cRoldxRZR+TyxtajGa UA77egK7rqoR01nOLEnmXLkmSfEQbxC5/u6mbTwKLO831D2MAS4L54Kg2tnffDcsEBgX SkNos4YOG65CVpyV3PsRqitX1yhZOSvXLdk67hbRnfIaQ3b32S3cyqDxVYi+HFK9JJof kTQ7esPedvHwjyV95+iBzVo33ITqWWp32p53u445JkggaNvjHt3HFUFGMRpHtTF4ouuf 7Ojg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=pW4K4AvzBHmxkbEdfM4KnnSmyTZcN+7Bx7ziinqgc7U=; b=aLSBVSQwkKaL6MlDWeV+ZK9Emi+cSwXVmQn6n6fqo9Isuxfh4c0aZxL9BjwDtAtQMA vpXvdX7/m/5gCxTU6QsZ7Ify9+VvzChKm1lZWs0DRkNNtycjwV9UeQmLZPmrIQaTF2gP 6Xk3qM4U+bQVQ/IMTJRMGIfmZZ9sSW5Vr1fx+wbDzg+7dU2jpjWLvxOwaeuaulfIrdd/ axGwNk+M5KGb4ahvu2k1X/HzyrMAkrjDAYc0PgQaVD8JwNH5xQPLBEq85HJJ5sIwA5NS yu5hPa/vIx5A9lGzkYE40J8Xl2Du0Rwk1Z07wQZAEyMEVf+wpL21fFovyB+Q/MhfeQAH FNKQ== X-Gm-Message-State: AD7BkJK+eygFNKb77kN0H7pLLxCrqhwXDi9LxqaKspxQbglh9gz4gzqht3ZL7foZeZahig== X-Received: by 10.194.84.66 with SMTP id w2mr19362342wjy.6.1456827501432; Tue, 01 Mar 2016 02:18:21 -0800 (PST) Received: from [172.24.251.185] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id g3sm30270907wjw.31.2016.03.01.02.18.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 02:18:20 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B12A0D09-7248-43B6-A78D-F5C87673C55A" From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 1 Mar 2016 12:18:16 +0200 Message-Id: <525F15F5-1A81-4EA7-9109-6F437BFB36DC@gmail.com> References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> <70EEDD2843564D589DCE9E96C84CB236@buildpc> <56D07E24.1040805@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org, "Waltermire, David A." Subject: Re: [IPsec] Textual changes to the DDoS draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:18:25 -0000 --Apple-Mail=_B12A0D09-7248-43B6-A78D-F5C87673C55A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think SHOULD is strong enough. > On 1 Mar 2016, at 8:07 AM, Valery Smyslov wrote: >=20 > Hi Yaron, > =20 > I also think that it's more safe to verify all 4 results (that's why = it's SHOULD).=20 > If nobody objects we can make it MUST for the sake of security and = simplicity. > =20 > Regards, > Valery. > =20 >> ----- Original Message -----=20 >> From: Yaron Sheffer >> To: Valery Smyslov ; Yoav Nir = ; Waltermire, David A. = >> Cc: ipsec@ietf.org >> Sent: Friday, February 26, 2016 7:32 PM >> Subject: Re: [IPsec] Textual changes to the DDoS draft >>=20 >> After reading the pull request, I suggest that we require the = responder to verify all 4 puzzles. Although I don't have a proof why = this is better (e.g. a game theoretic cost/benefit analysis), it would = remove an unnecessary design decision from implementations at a trivial = cost in performance. >>=20 >> Thanks, >> Yaron >>=20 >> On 02/25/2016 09:50 PM, Valery Smyslov wrote: >>> That was also my impression. And the draft is already being edited = to include multiple puzzles. >>> =20 >>> Valery. >>>> ----- Original Message -----=20 >>>> From: Yoav Nir >>>> To: Waltermire, David A. >>>> Cc: ipsec@ietf.org = WG=20 >>>> Sent: Friday, February 26, 2016 8:43 AM >>>> Subject: Re: [IPsec] Textual changes to the DDoS draft >>>>=20 >>>>=20 >>>>> On 26 Feb 2016, at 2:03 AM, Waltermire, David A. < = david.waltermire@nist.gov = > wrote: >>>>>=20 >>>>> I haven=92t seen any additional feedback on the DDoS draft this = week based on Yoav=92s note about the PR [1]. It also looks like the = discussion on chaining puzzles has wrapped up with no changes needed to = the draft [2]. >>>>=20 >>>> Oh. My impression of [2] was that Valery and I were in agreement = that this change was a good idea, with Scott and Yaron supporting (not = quite as enthusiastically) and with not opinions to the contrary. Valery = and I thought we=92d make this change over the weekend.=20 >>>>=20 >>>> Yoav >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec = >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec = >>=20 >=20 --Apple-Mail=_B12A0D09-7248-43B6-A78D-F5C87673C55A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think SHOULD is strong enough.


On 1 Mar 2016, at 8:07 AM, = Valery Smyslov <svanru@gmail.com> wrote:

Hi Yaron,
 
I also think that it's more safe = to verify all 4 results (that's why it's SHOULD). 
If nobody objects we can make it = MUST for the sake of security and simplicity.
 
Regards,
Valery.
 
----- Original Message ----- 
From: Yaron Sheffer
To: Valery Smyslov ; Yoav Nir ; Waltermire, David = A.
Cc: ipsec@ietf.org
Sent: Friday, February 26, 2016 = 7:32 PM
Subject: Re: [IPsec] Textual changes = to the DDoS draft

After = reading the pull request, I suggest that we require the responder to = verify all 4 puzzles. Although I don't have a proof why this is better = (e.g. a game theoretic cost/benefit analysis), it would remove an = unnecessary design decision from implementations at a trivial cost in = performance.

Thanks,
    Yaron

On 02/25/2016 09:50 PM, Valery Smyslov = wrote:
That was also my = impression. And the draft is already being edited to include multiple = puzzles.
 
Valery.
----- Original Message ----- 
From: Yoav Nir
To: Waltermire, David A.
Cc: ipsec@ietf.org WG 
Sent: Friday, February 26, 2016 = 8:43 AM
Subject: Re: [IPsec] Textual changes = to the DDoS draft


On 26 Feb 2016, at 2:03 AM, Waltermire, David A. <david.waltermire@nist.gov>= ; wrote:

I haven=92t seen any = additional feedback on the DDoS draft this week based on Yoav=92s note = about the PR [1]. It also looks like the discussion on chaining puzzles = has wrapped up with no changes needed to the draft = [2].

Oh. My impression of [2] was that Valery and I = were in agreement that this change was a good idea, with Scott and Yaron = supporting (not quite as enthusiastically) and with not opinions to the = contrary. Valery and I thought we=92d make this change over the = weekend. 

Yoav


_______________________________________________
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



= --Apple-Mail=_B12A0D09-7248-43B6-A78D-F5C87673C55A-- From nobody Tue Mar 1 07:33:52 2016 Return-Path: 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 187A51B2D5E for ; Tue, 1 Mar 2016 07:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 6Ca1knl7tU_p for ; Tue, 1 Mar 2016 07:33:48 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE34D1B2D5D for ; Tue, 1 Mar 2016 07:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dAcq556Sd250Zg16w8iQyPzWmMePm4paJNjaze6Nkrw=; b=mhI0OWv6nmW+fnpkFYHXBGqtdOzakSQzjKadn9gRUMigLlU1G7duTVqevdqLepuHcRK8b6bZFiJQZqgEqrItGGC4YNPMo1xmXwe4feFut4uhG2Xn/QAosI/wWghAgV4AzRX47Zy+KMCNfjNo5XFiOfutVLHzlOSr2OR2BbJhHxg= Received: from BY1PR09MB0358.namprd09.prod.outlook.com (10.160.105.28) by BY1PR09MB0357.namprd09.prod.outlook.com (10.160.105.27) with Microsoft SMTP Server (TLS) id 15.1.415.20; Tue, 1 Mar 2016 15:33:46 +0000 Received: from BY1PR09MB0358.namprd09.prod.outlook.com ([10.160.105.28]) by BY1PR09MB0358.namprd09.prod.outlook.com ([10.160.105.28]) with mapi id 15.01.0415.022; Tue, 1 Mar 2016 15:33:46 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQ== Date: Tue, 1 Mar 2016 15:33:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0357; 5:IaBF4rnfndpTdyLX7Rpxh4jnLkUANgaDlmTBgCXd1K0KlGftmK5gSRh3WblkzekPrsacRT4gUfiVBYcmdu8kn7l38ohEOmcHet/uLGf1y4FAJfTpfkOXvtnBhYGGjeD7ASE5FzXwDFsX1tKCtTILfA==; 24:HFJcp3Yr5npRnH4S5AIekg7BJqZZGvftynZrac91N/7vzWJSNLF5SZeBCP4IZkWvk1IZHNPATpJzQ6xfKJw0z8n8adcI2Cq0d2iKnGKIpgs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0357; x-ms-office365-filtering-correlation-id: 78f05b91-9734-45ad-870c-08d341e6e152 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR09MB0357; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0357; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189998001)(102836003)(3846002)(586003)(6116002)(99286002)(40100003)(50986999)(5002640100001)(450100001)(66066001)(1220700001)(230783001)(122556002)(5001960100003)(77096005)(5008740100001)(19580395003)(1096002)(5003600100002)(33656002)(2900100001)(76576001)(2906002)(86362001)(74316001)(11100500001)(3280700002)(3660700001)(87936001)(15975445007)(229853001)(5004730100002)(107886002)(92566002)(54356999)(10400500002)(110136002)(81156008); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0357; H:BY1PR09MB0358.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 15:33:46.1843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0357 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 15:33:52 -0000 All: With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe th= e draft is shaping up nicely, but needs additional review. To that end, thi= s message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-dd= os-protection-04. The version to be reviewed is https://tools.ietf.org/id/draft-ietf-ipsecme-= ddos-protection-04.txt. Please send your comments, questions, and edit proposals to the WG mail lis= t until March 18, 2015. If you believe that the document is ready to be su= bmitted to the IESG for consideration as a Standards Track RFC please send = a short message stating this. Best Regards, Dave From nobody Tue Mar 1 07:34:10 2016 Return-Path: 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 6D1371B2D72 for ; Tue, 1 Mar 2016 07:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 XCpOn_RfbRTp for ; Tue, 1 Mar 2016 07:34:03 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0109.outbound.protection.outlook.com [23.103.200.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4F91B2D51 for ; Tue, 1 Mar 2016 07:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MPRJ86IWboPo6wD5t6JsSRTOloxouxoSFv6y/ghbosg=; b=g4InRnRFcKkJ0sk+vUJ7tP5AZQfPN2XoJPHvnxyEgOvKpuitdhn+Ya5ZV9Dhp8e9LmgLxvzcxTPJoCMjkGOt0XPc3JGL/QMijeeyad4EBQEZH4o5nIo3ExUqOGcW6MpUxw7ip1fnREJvBI7FUdjDL+xqg9JykmvB/4uapXBAilY= Received: from BY1PR09MB0358.namprd09.prod.outlook.com (10.160.105.28) by BY1PR09MB0360.namprd09.prod.outlook.com (10.160.106.12) with Microsoft SMTP Server (TLS) id 15.1.415.20; Tue, 1 Mar 2016 15:34:01 +0000 Received: from BY1PR09MB0358.namprd09.prod.outlook.com ([10.160.105.28]) by BY1PR09MB0358.namprd09.prod.outlook.com ([10.160.105.28]) with mapi id 15.01.0415.022; Tue, 1 Mar 2016 15:34:01 +0000 From: "Waltermire, David A. (Fed)" To: Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] Textual changes to the DDoS draft Thread-Index: AQHRbWMiakRhWjG5V0W8hGiSgOCOwp89czsggABjQQCAAAHYg4AAs38AgAWazdiAAEXwAIAAVK6A Date: Tue, 1 Mar 2016 15:34:01 +0000 Message-ID: References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> <70EEDD2843564D589DCE9E96C84CB236@buildpc> <56D07E24.1040805@gmail.com> <525F15F5-1A81-4EA7-9109-6F437BFB36DC@gmail.com> In-Reply-To: <525F15F5-1A81-4EA7-9109-6F437BFB36DC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-microsoft-exchange-diagnostics: 1; BY1PR09MB0360; 5:DMfHeADr0KoMWokr7oxPsAZ3wNAv0iIOenpXP9zabiQZi5q8buKu3m/2czcJLdrKK5vqkXKKW44i860QC1oJ3pT2GeLGvwdxKG0XFK/SilG48BJ3PP11Ydzd037mredFuvCqF/w/AQxwxxvBVOHvKA==; 24:VnI5EU7cTlQnbp2RllA2egOsz3ioX17QWObgO0kxn2lpuE6yGN4dKZf1CwsxUAIf+Nm0u2+t/FCJjSZcB0lSVa49v2LVhDt/q1R4CECXuI8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0360; x-ms-office365-filtering-correlation-id: 12ce7d86-083f-4afe-da75-08d341e6ea39 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY1PR09MB0360; BCL:0; PCL:0; RULEID:; SRVR:BY1PR09MB0360; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(479174004)(24454002)(377454003)(164054003)(13464003)(76576001)(86362001)(2950100001)(5004730100002)(2900100001)(54356999)(92566002)(76176999)(1096002)(1220700001)(50986999)(5002640100001)(19580405001)(5003600100002)(19609705001)(77096005)(15975445007)(790700001)(40100003)(5001960100003)(102836003)(189998001)(81156008)(6116002)(11100500001)(3846002)(19580395003)(586003)(74316001)(5008740100001)(5001770100001)(19625215002)(99286002)(106116001)(33656002)(16236675004)(19300405004)(2906002)(3660700001)(93886004)(10400500002)(122556002)(19617315012)(87936001)(3280700002)(4326007)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0360; H:BY1PR09MB0358.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR09MB0358BBA3D9E9BB13C2A939CBF0BB0BY1PR09MB0358namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 15:34:01.5127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0360 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Textual changes to the DDoS draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 15:34:09 -0000 --_000_BY1PR09MB0358BBA3D9E9BB13C2A939CBF0BB0BY1PR09MB0358namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks like the freshly posted -04 draft has this requirement as a MUST. = Let's hash this out during the WGLC. If we need to make any changes we can = make them all after the call concludes. Thanks, Dave From: Yoav Nir [mailto:ynir.ietf@gmail.com] Sent: Tuesday, March 01, 2016 5:18 AM To: Valery Smyslov Cc: Waltermire, David A. (Fed) ; Yaron Sheffer <= yaronf.ietf@gmail.com>; ipsec@ietf.org Subject: Re: [IPsec] Textual changes to the DDoS draft I think SHOULD is strong enough. On 1 Mar 2016, at 8:07 AM, Valery Smyslov > wrote: Hi Yaron, I also think that it's more safe to verify all 4 results (that's why it's S= HOULD). If nobody objects we can make it MUST for the sake of security and simplici= ty. Regards, Valery. ----- Original Message ----- From: Yaron Sheffer To: Valery Smyslov ; Yoav Nir ; Waltermire, David A. Cc: ipsec@ietf.org Sent: Friday, February 26, 2016 7:32 PM Subject: Re: [IPsec] Textual changes to the DDoS draft After reading the pull request, I suggest that we require the responder to = verify all 4 puzzles. Although I don't have a proof why this is better (e.g= . a game theoretic cost/benefit analysis), it would remove an unnecessary d= esign decision from implementations at a trivial cost in performance. Thanks, Yaron On 02/25/2016 09:50 PM, Valery Smyslov wrote: That was also my impression. And the draft is already being edited to inclu= de multiple puzzles. Valery. ----- Original Message ----- From: Yoav Nir To: Waltermire, David A. Cc: ipsec@ietf.org WG Sent: Friday, February 26, 2016 8:43 AM Subject: Re: [IPsec] Textual changes to the DDoS draft On 26 Feb 2016, at 2:03 AM, Waltermire, David A. > wrote: I haven't seen any additional feedback on the DDoS draft this week based on= Yoav's note about the PR [1]. It also looks like the discussion on chainin= g puzzles has wrapped up with no changes needed to the draft [2]. Oh. My impression of [2] was that Valery and I were in agreement that this = change was a good idea, with Scott and Yaron supporting (not quite as enthu= siastically) and with not opinions to the contrary. Valery and I thought we= 'd make this change over the weekend. Yoav ________________________________ _______________________________________________ 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 --_000_BY1PR09MB0358BBA3D9E9BB13C2A939CBF0BB0BY1PR09MB0358namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It looks like the freshly posted -04 = draft has this requirement as a MUST. Let’s hash this out during the = WGLC. If we need to make any changes we can make them all after the call concludes.

 

Thanks,

Dave

 

From: Yoav Nir [mailto:ynir.ietf@gma= il.com]
Sent: Tuesday, March 01, 2016 5:18 AM
To: Valery Smyslov <svanru@gmail.com>
Cc: Waltermire, David A. (Fed) <david.waltermire@nist.gov>; Ya= ron Sheffer <yaronf.ietf@gmail.com>; ipsec@ietf.org
Subject: Re: [IPsec] Textual changes to the DDoS draft

 

I think SHOULD is strong enough.

 

 

On 1 Mar 2016, at 8:07 AM, Valery Smyslov <svanru@gmail.com> wrote:

 

Hi Yaron,

 

I also think that it's= more safe to verify all 4 results (that's why it's SHOULD). 

If nobody objects we c= an make it MUST for the sake of security and simplicity.

 

Regards,=

Valery.<= /o:p>

 

----- Original Message ---= -- 

From: Yaron Sheffer

To: Valery Smyslov ; Yoav Nir ; <= a href=3D"mailto:david.waltermire@nist.gov" title=3D"david.waltermire@nist.= gov">Waltermire, David A.

Sent: Friday, February 26, 2016 7:32 PM

Subject: Re: [IPsec] Textual changes to the DDoS draft

 

Af= ter reading the pull request, I suggest that we require the responder to ve= rify all 4 puzzles. Although I don't have a proof why this is better (e.g. a game theoretic cost/benefit analysis), it would= remove an unnecessary design decision from implementations at a trivial co= st in performance.

Thanks,
    Yaron

On 02/25/2016 09:50 PM,= Valery Smyslov wrote:

That was also my impre= ssion. And the draft is already being edited to include multiple puzzles.

 

Valery.<= /o:p>

----- Original Message ---= -- 

From: Yoav Nir

Cc: ipsec@ietf.org = WG 

Sent: Friday, February 26, 2016 8:43 AM

Subject: Re: [IPsec] Textual changes to the DDoS draft

 

 

On 26 Feb 2016, at 2:03= AM, Waltermire, David A. <= david.waltermire@nist.gov> wrote:

 

I haven= 217;t seen any additional feedback on the DDoS draft this week based on Yoa= v’s note about the PR [1]. It also looks like the discussion on chaining puzzles has wrapped up with no changes needed to the draft [2]= .

 

Oh. My impression of [2= ] was that Valery and I were in agreement that this change was a good idea,= with Scott and Yaron supporting (not quite as enthusiastically) and with not opinions to the contrary. Valery and I thought we’d mak= e this change over the weekend. =

 

Yoav<= /p>

 

 

_______________________= ________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec




___________________________________________=
____
IPsec mailing list
IPsec@iet=
f.org
https://www.ietf.org/mailman/listinfo/ipsec

 

 

 

--_000_BY1PR09MB0358BBA3D9E9BB13C2A939CBF0BB0BY1PR09MB0358namp_-- From nobody Tue Mar 1 08:18:27 2016 Return-Path: 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 72BC91B2E33 for ; Tue, 1 Mar 2016 08:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 nmfbSl8LEehY for ; Tue, 1 Mar 2016 08:18:25 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 99DAC1B2E30 for ; Tue, 1 Mar 2016 08:18:25 -0800 (PST) Received: from [192.168.114.1] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u21GILHl099657 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Mar 2016 09:18:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "IPsecME WG" Date: Tue, 01 Mar 2016 08:18:20 -0800 Message-ID: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:18:26 -0000 Greetings. We need to update our charter to reflect our current and expected work. Dave and I propose the following text. Please let us know within the next week if you have suggestions for changes. --Paul Hoffman and Dave Waltermire The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to- implement (MTI) algorithms are defined in RFC4307. There is interest in updating the MTIs in RFC4307 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 proposing updates to the MIT algorithms used by IKEv2 to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. This charter will expire in August 2016. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. From nobody Tue Mar 1 09:08:01 2016 Return-Path: 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 497831B2FA6 for ; Tue, 1 Mar 2016 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 iHRkrs2j7Z2d for ; Tue, 1 Mar 2016 09:07:53 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4B6821B2FC4 for ; Tue, 1 Mar 2016 09:07:50 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u21H7m43031581 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Mar 2016 17:07:49 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u21H7l3n011290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 17:07:47 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u21H7lIw028027; Tue, 1 Mar 2016 17:07:47 GMT MIME-Version: 1.0 Message-ID: <615bd04b-b000-4680-b755-f89e55a0daf0@default> Date: Tue, 1 Mar 2016 09:07:46 -0800 (PST) From: Victor Pascual Avila Sender: Victor Pascual Avila To: Paul Hoffman , IPsecME WG References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> In-Reply-To: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 15.0.4797.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:07:59 -0000 Shall we include firewall traversal/TCP encapsulation as part of the charte= r as discussed in draft-pauly-ipsecme-tcp-encaps? Cheers, -Victor -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: 01 March 2016 17:18 To: IPsecME WG Subject: [IPsec] Proposed wording for a revised charter Greetings. We need to update our charter to reflect our current and expecte= d work. Dave and I propose the following text. Please let us know within th= e next week if you have suggestions for changes. --Paul Hoffman and Dave Waltermire The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is = widely deployed in VPN gateways, VPN remote access clients, and as a substr= ate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of th= e earlier IPsec Working Group which was concluded in 2005. Its purpose is t= o maintain the IPsec standard and to facilitate discussion of clarification= s, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Group= s who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service at= tacks. However this mechanism cannot protect an IKE end-point (typically, a= large gateway) from "distributed denial of service", a coordinated attack = by a large number of "bots". The working group will analyze the problem and= propose a solution, by offering best practices and potentially by extendin= g the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide sec= urity services. To support interoperability a number of mandatory-to- imple= ment (MTI) algorithms are defined in RFC4307. There is interest in updating= the MTIs in RFC4307 based on new algorithms, changes to the understood security strengt= h of existing algorithms, and the degree of adoption of previously introduc= ed algorithms. The group will revise RFC4307 proposing updates to the MIT a= lgorithms used by IKEv2 to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key e= xchange in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their relate= d functions. This charter will expire in August 2016. If the charter is not updated befo= re that time, the WG will be closed and any remaining documents revert back= to individual Internet-Drafts. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Mar 1 12:32:30 2016 Return-Path: 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 543421B4163 for ; Tue, 1 Mar 2016 12:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 uk1hV3PvcWjX for ; Tue, 1 Mar 2016 12:32:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 6C9731B4152 for ; Tue, 1 Mar 2016 12:32:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qF99z5tqczJvD; Tue, 1 Mar 2016 21:32:23 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id x3ORR7Q3m-cP; Tue, 1 Mar 2016 21:32:21 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 1 Mar 2016 21:32:21 +0100 (CET) Received: from [25.124.234.10] (unknown [24.114.52.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 9D6CB614B067; Tue, 1 Mar 2016 15:32:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9D6CB614B067 References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13C75) From: Paul Wouters Date: Tue, 1 Mar 2016 15:32:17 -0500 To: Paul Hoffman Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:32:28 -0000 S/mostly//=20 Add IKE over tcp and DNS extensions for ikev2? Sent from my iPhone > On Mar 1, 2016, at 11:18, Paul Hoffman wrote: >=20 > Greetings. We need to update our charter to reflect our current and expect= ed work. Dave and I propose the following text. Please let us know within th= e next week if you have suggestions for changes. >=20 > --Paul Hoffman and Dave Waltermire >=20 >=20 > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs)= , > IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is= > widely deployed in VPN gateways, VPN remote access clients, and as a > substrate for host-to-host, host-to-network, and network-to-network > security. >=20 > The IPsec Maintenance and Extensions Working Group continues the work of > the earlier IPsec Working Group which was concluded in 2005. Its purpose i= s > to maintain the IPsec standard and to facilitate discussion of clarificati= ons, > improvements, and extensions to IPsec, mostly to IKEv2. > The working group also serves as a focus point for other IETF Working Grou= ps > who use IPsec in their own protocols. >=20 > The current work items include: >=20 > IKEv2 contains the cookie mechanism to protect against denial of service > attacks. However this mechanism cannot protect an IKE end-point (typically= , > a large gateway) from "distributed denial of service", a coordinated attac= k by > a large number of "bots". The working group will analyze the problem and > propose a solution, by offering best practices and potentially by extendin= g > the protocol. >=20 > IKEv2 utilizes a number of cryptographic algorithms in order to provide > security services. To support interoperability a number of mandatory-to- > implement (MTI) algorithms are defined in RFC4307. There is interest in > updating the MTIs in > RFC4307 based on new algorithms, changes to the understood security > strength of existing algorithms, and the degree of adoption of previously > introduced algorithms. The group will revise RFC4307 proposing updates to > the MIT algorithms used by IKEv2 to address these changes. >=20 > There is interest in supporting Curve25519 and Curve448 for ephemeral key > exchange in the IKEv2 protocol. The group will extend the > IKEv2 protocol to support key agreement using these curves and their > related functions. >=20 > This charter will expire in August 2016. If the charter is not updated bef= ore > that time, the WG will be closed and any remaining documents revert back t= o > individual Internet-Drafts. >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 4 00:05:45 2016 Return-Path: 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 8D8AA1B34B6 for ; Fri, 4 Mar 2016 00:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 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, HTML_OBFUSCATE_05_10=0.26, J_CHICKENPOX_82=0.6, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] 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 4ZiWkAS5tf3z for ; Fri, 4 Mar 2016 00:05:40 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080711B34B4 for ; Fri, 4 Mar 2016 00:05:40 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id cf7so35740096lbb.1 for ; Fri, 04 Mar 2016 00:05:39 -0800 (PST) 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; bh=J4CxfbgWjiTECFx53RYqSsIEXSS41h5mwhwxk7y6rTk=; b=ecY8WWwHjVM7zwy1EVge5Cg+/4S1iQ+UCuRAsBg6pHz6xbWIjBzaSFtw9RUc/26J93 yWnVhjgUW5/ULVUIo+Fl265oVTNAJcF7PuW3Xsdnb/oYfjmFuowS/mmePzBMJSuv/2tn VA9imq/iKwGz5pllfEXYJ3xvyYzunllNv8kIEXjLqUfjVDu/RVFKlYzKzf4fBB7CnE1t rIeAZC/3rB9+mwKJ2f+t4uf+s6lsGlWSdzedhLRmZKhK360+DwHDf4kwh+3hT9LAh1bT YouvMXRUPJVjiNQmk18UvykqvVG+ok1WEfj40HFj5o1mruFa07f+AnMdf2kWqfspZEeD hnQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=J4CxfbgWjiTECFx53RYqSsIEXSS41h5mwhwxk7y6rTk=; b=aHuplWIgUqehSm9TsYJh6PQsS3YOOZ3mxk/C5UJDW/wAZffpJPF3gtJU235AYVmFvE ZmePVpLrL/eh5V7fpi+Xp48TcW2X4fLRWXXKYT3BNI/pK1H1qYvuA1SQ1AIGUgV3NPCq 976MkuVZ9D+tGs+G4vPXDwHkWuCJYT6JU/kG1cqKo8lFEDDAEdJ3EzJSrFB0k7ocTXtm Lg1sdsd5SLG1/4JwDkE3A4DOMvxspkSf4rZq00//8TBsXkQx2Oeiva6NSVPWTBT+BZDR n8Z7fbYVFE/IxkYMjqx2OfwGJSltY439+OhxuSrqpx0yaPKkA52yGRXRD71BUezmHXr7 H3YQ== X-Gm-Message-State: AD7BkJJkOF9vb4yNw5HBYHM9M03A7vjb9unnE/+c/HvMQCoathHIVv6agMcksKPxQ/dQnrFWpAV4iEJsv57x2A== MIME-Version: 1.0 X-Received: by 10.112.172.42 with SMTP id az10mr2576283lbc.128.1457078738151; Fri, 04 Mar 2016 00:05:38 -0800 (PST) Received: by 10.25.35.88 with HTTP; Fri, 4 Mar 2016 00:05:38 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 13:35:38 +0530 Message-ID: From: "Dr. Karan Verma" To: "Waltermire, David A. (Fed)" , ipsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c349ce98ecaf052d349493 Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 08:05:43 -0000 --001a11c349ce98ecaf052d349493 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Dave there are some suggestions and comments: 1. The root CA certificate corresponding to the server certificate must be installed on the client computers in the Trusted Root Certification Authorities per-computer certificate store. The client computer must be able to validate the server certificate as being signed by a trusted root CA. If you are already using SSTP connections, then you can use the same certificate for both SSTP and IKEv2, as long as the certificate meets the CN and EKU requirements identified previously. Because root CA certificates are required on client computers when using SSTP, adding a certificate for IKEv2 that was created by the same CA as an SSTP certificate means that no client changes are needed. 2. If I keep my user and server key to a 2048-bit one it appears to be fine. But, if I try to use a 4096-bit certificate for either the machine or the user's authentication the negotiation fails over anything but a local network connection, and it appears the reason it fails is fragmentation. In short the keying never gets to the server and thus does not complete. There's an RFC for this and support on recent Strong swan releases but the client has to ask for it during initial negotiation and the BB10 client does not. The result is that longer (and more-secure) keys won't work -- if you have either a 4096-bit server certificate or a 4096-bit user cert the VPN will not come up. 3. First, we have incompatibility between IPsec AH and NAT. This is because AH header incorporates the IP source and destination addresses in the keyed message integrity check and therefore NAT will invalidate message integrity check by changing address fields. This makes A unusable in the presence of NAT devices. ESP doesn't have this problem because it doesn't incorporate the IP header inits keyed message integrity check, so changes in IP header will not conflict with ESP's integrity protection. A more serious problem that affects both AH and ESP is incompatibility between transport layer checksums and NAT. This problem occurs with AH and ESP in transport mode. Namely, TCP and UDP checksums depend on source and destination addresses and ports because of their inclusion in "pseudo-header" during transport protocol checksum calculations and verifications. When a NAT box changes source and/or destination address/port it can-not change the checksum since it's protected by either or both ESP and AH. The partial solution is to use ESP in tunnel mode, but in this case inner IP address, protected by NAT, is visible to the node. There is also incompatibility between IKEv2 address identifiers and NAT. Some phases of IKEv2 use IP addresses as identifiers. Modification of these addresses through NAT will cause mismatch between identifiers and the addresses in the IP header. The solution to this problem might be the use of user IDs or FQDNs that are independent of IP addresses. IKE protocol requires use of fixed source and destination ports. This also causes incompatibility with NAT. One possible scenario that might cause problems is when multiple hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same responder. Mechanism is needed to allow the NAPT to DE multiplex the incoming IKE packets from responder. This is typically accomplished by translating the IKE UDP source port on outbound packets from initiator. Because of that responders must be able to accept IKE traffic from a various source ports (other than 500 on which is IKE running), and must reply to that port. The somewhat similar problem, but in it's own category, are the incompatibilities between overlapping SPD entries when using NAT. There are situations when responder could send packets down the wrong IPsec SA because of overlapping SPD entries. This could happen when initiating hosts behind NAT use their source IP addresses in Phase 2 identifiers. Another problem between ESP and NAT lies in thein compatibility between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted, only way for NATs to know how to demultiplex incoming packets is to inspect information=E2=80=99s in the IP and ESP head= er. These information=E2=80=99s are usually destination IP address, IPsec SPI a= nd security protocol (every SA is uniquely determined by this three elements). Because of independent selection of incoming and outgoing SPIs it is possible that the NAT will deliver the incoming IPsec packets to the wrong place when two hosts behind the NAT attempt to create IPsec SAs at the same destination simultaneously. Namely, this destination could choose same SPIs and there is no way for NAT to know to which SA belong incoming packets from this destination. Thus, NAT neither knows where to deliver these incoming packets. Technique that can alleviate this problem is that receiving host (the one who generated same SPIs in our case) allocate a unique SPI to each unicast SA. We have already mentioned that protocols who embed IP address within payload have a problem with NAT boxes. IPsec and its protocols aren't exception =E2=80=93 payload could be integrity protected and NAT couldn't translate IP addresses embedded within payload. Solution for this problem is to install ALGs (Application Layer Gateways)on the host or security gateway. These ALGs should have a possibility of operating on application traffic before IP sec encapsulation and after IPsec decapsulation the NAT provides IPv6 nodes with specific IPv6 prefix. This prefix is retrieved from the NAT external IPv4 address. A part from providing the prefix, NAT also encapsulates IPv6 packets in IPv4 for transport to other 6to4 nodes or relays. This method gives a possibility for communication without problems between an IPv6 node using IPsec and other nodes inside the IPv6 or 6 to 4 area. Unfortunately, 6to4 is not universally usable. It is an appropriate solution where a single NAT separates a client and the VPN gateway but it cannot be used where multiple NATs are deployed between client an= d VPN gateway. Reason for this is that forming of mentioned IPv6 prefix requires the assignment of a routable IPv4 address to the NAT. Peers that support IPv6 need a little upgrade to be 6to4compatible, while NATs require many extensions to support 6 to 4. On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > All: > > With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe > the draft is shaping up nicely, but needs additional review. To that end, > this message starts a Working Group Last Call (WGLC) for > draft-ietf-ipsecme-ddos-protection-04. > > The version to be reviewed is > https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. > > Please send your comments, questions, and edit proposals to the WG mail > list until March 18, 2015. If you believe that the document is ready to = be > submitted to the IESG for consideration as a Standards Track RFC please > send a short message stating this. > > Best Regards, > Dave > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258 --001a11c349ce98ecaf052d349493 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Dave=C2=A0

there are some suggest= ions and comments:=C2=A0

1. The root CA certificate correspond= ing to the server certificate must be installed on the client computers in the Trusted Root Certification Authorities per-computer certificate store. The client comput= er must be able to validate the server certificate as being signed by a truste= d root CA.

If you ar= e already using SSTP connections, then you can use the same certificate for both SSTP and IKEv2, as long as the certificat= e meets the CN and EKU requirements identified previously. Because root CA certificates are required on client computers when using SSTP, adding a certificate for IKEv2 that was created by the same CA as an SSTP certificat= e means that no client changes are needed.

=C2=A0

2. If I k= eep my user and server key to a 2048-bit one it appears to be fine.=C2=A0 But, if I try to use a 4096-bit certificate for either the machine or the user's authenticat= ion the negotiation fails over anything but a local network connection, and it appe= ars the reason it fails is fragmentation.=C2=A0 In short the keying never gets to the server and thus does not complete.

There'= ;s an RFC for this and support on recent Strong swan releases but the client has to ask for it during initial negotiation and th= e BB10 client does not.=C2=A0 The result is that longer (and more-secure) keys won't work -- if you have either a 4096-b= it server certificate or a 4096-bit user cert the VPN will not come up.=

=C2=A0

=C2=A03. = First, we have incompatibility between IPsec AH and NAT.=C2=A0=C2=A0 This=C2=A0=C2=A0 is=C2=A0=C2=A0 because=C2=A0=C2=A0 AH=C2=A0=C2=A0 header=C2=A0=C2=A0 incorporates=C2=A0=C2=A0 the=C2=A0=C2=A0 IP source=C2=A0=C2=A0 and=C2=A0=C2=A0 destination=C2=A0=C2=A0 addresses=C2=A0=C2=A0 in the keyed message integrity check and therefore NAT will invalidate mess= age integrity check by changing address fields. This makes A unusable in the presence of NAT devices. ESP doesn't have this problem because it doesn= 't incorporate the IP header inits keyed message integrity check, so changes i= n IP header will not conflict with ESP's integrity protection.

A more se= rious problem that affects both AH and ESP is incompatibility between=C2=A0=C2=A0 transport=C2=A0=C2=A0 layer=C2=A0=C2=A0 checksums=C2=A0=C2=A0 and NAT. This problem occurs with AH and ESP in transport mode.=C2=A0=C2=A0 Namely,=C2=A0=C2=A0 TCP=C2=A0=C2=A0 and=C2=A0=C2=A0 UDP=C2=A0=C2=A0 checksums=C2=A0=C2=A0 depend=C2=A0=C2=A0 on source and destination addresses and ports because of their inclusion=C2= =A0=C2=A0 in=C2=A0=C2=A0 "pseudo-header"=C2=A0=C2=A0 during=C2=A0=C2=A0 transport=C2=A0=C2=A0 protocol checksum calculations and verifications. When a NAT box changes source and/or destination address/por= t it can-not change the checksum since it's protected by either or both ESP = and AH. The partial solution is to use ESP in tunnel mode, but in this case inner I= P address, protected by NAT, is visible to the node.

There is = also incompatibility between IKEv2 address identifiers=C2=A0=C2=A0 and=C2= =A0=C2=A0 NAT.=C2=A0=C2=A0 Some=C2=A0=C2=A0 phases=C2=A0=C2=A0 of=C2=A0=C2=A0 IKEv2=C2=A0=C2=A0 use=C2=A0=C2=A0 IP addresses as identifiers. Modification of these addresses through NAT will cause mismatch between identifiers and the addresses in the IP header.= The solution to this problem might=C2=A0=C2=A0 be=C2=A0=C2=A0 the=C2=A0=C2=A0 use=C2=A0=C2=A0 of=C2=A0=C2=A0 user=C2=A0=C2=A0 IDs=C2=A0=C2=A0 or=C2=A0=C2=A0 FQDNs=C2=A0=C2=A0 that=C2=A0=C2=A0 are independent of IP addresses. IKE=C2=A0=C2=A0 protocol=C2=A0=C2=A0 requires=C2=A0=C2=A0 use=C2=A0=C2=A0 of=C2=A0=C2=A0 fixed=C2=A0=C2=A0 source=C2=A0=C2=A0 and destination=C2=A0=C2=A0 ports.=C2=A0=C2=A0 This=C2=A0=C2=A0 also=C2=A0=C2=A0 causes=C2=A0=C2=A0 incompatibility with NAT. One possible scenario that might cause problems is when multiple hosts behind the NAT (NAPT to be precise) initiat= e IKE SAs to the same responder. Mechanism is needed to allow the NAPT to DE multiplex the incoming IKE=C2=A0=C2=A0 packets=C2=A0=C2=A0 from=C2=A0=C2=A0 responder.=C2=A0=C2=A0 This=C2=A0=C2=A0 is=C2=A0=C2=A0 typically accomplished by translating the IKE UDP source port on outbound= =C2=A0=C2=A0 packets=C2=A0=C2=A0 from=C2=A0=C2=A0 initiator.=C2=A0=C2=A0 Because=C2=A0=C2=A0 of=C2=A0=C2=A0 that responders=C2=A0=C2=A0 must=C2=A0=C2=A0 be=C2=A0=C2=A0 able=C2=A0=C2=A0 to=C2=A0=C2=A0 accept=C2=A0=C2=A0 IKE=C2=A0=C2=A0 traffic=C2=A0=C2=A0 from=C2=A0=C2=A0 a various=C2=A0 source=C2=A0 ports=C2=A0=C2=A0 (other=C2=A0 than=C2=A0 500=C2=A0=C2=A0 on=C2=A0 which=C2=A0 is=C2=A0 IKE running), and must reply to that port. The somewhat similar problem, but in it's own category, a= re the incompatibilities between overlapping SPD entries when using NAT.=C2=A0=C2= =A0 There are situations when responder could send packets down the wrong IPsec SA because of overlapping=C2=A0=C2=A0 SPD= =C2=A0=C2=A0 entries.=C2=A0=C2=A0 This=C2=A0=C2=A0 could=C2=A0 =C2=A0happen=C2=A0=C2=A0 when initiating hosts behind NAT use their source IP addresses in Phase 2 identifiers. Another problem between ESP =C2= =A0and NAT=C2=A0=C2=A0 lies=C2=A0 in=C2=A0 thein compatibility=C2=A0=C2=A0 between=C2=A0=C2=A0 IPsec=C2=A0=C2=A0 SPI=C2=A0=C2=A0 selection=C2=A0=C2=A0 and=C2=A0=C2=A0 NAT. Since IPsec ESP traffic is encrypted, only way for NATs to know how to demultiplex incoming packets= is to inspect information=E2=80=99s in the IP and ESP header. These informatio= n=E2=80=99s are usually destination IP address, IPsec SPI and security protocol (every SA i= s uniquely determined by this three elements). Because of independent selecti= on of incoming and outgoing SPIs it is possible that the NAT will deliver the incoming IPsec packets to the wrong place when two hosts behind the NAT att= empt to create IPsec SAs at the same destination simultaneously. Namely, this de= stination could choose same SPIs and there is no way for NAT to know to which SA belo= ng=C2=A0=C2=A0 incoming packets from this destination. Thus, NAT neither knows where to deliver these incoming packets. Technique = that can alleviate this problem is that receiving host (the one who generated sa= me SPIs in our case) allocate a unique SPI to each unicast SA. We have already mentioned that protocols who embed IP=C2=A0=C2=A0 address=C2=A0=C2=A0 within=C2=A0=C2=A0 payload=C2=A0=C2=A0 have=C2=A0=C2=A0 a=C2=A0=C2=A0 problem=C2=A0=C2=A0 with=C2=A0=C2=A0 NAT boxes. IPsec and its protocols aren't exception =E2=80=93 payload could be integrity protect= ed and NAT couldn't translate IP addresses=C2=A0=C2=A0 embedded=C2=A0=C2=A0 within=C2=A0=C2=A0 payload.=C2=A0=C2=A0 Solution=C2=A0=C2=A0 for=C2=A0=C2=A0 this problem is to install ALGs (Appli= cation Layer Gateways)on the host or security gateway. These ALGs should have a po= ssibility of operating on application traffic before IP sec encapsulation and after I= Psec decapsulation the NAT provides IPv6=C2=A0=C2=A0 nodes=C2=A0=C2=A0 with=C2=A0=C2=A0 specific=C2=A0=C2=A0 IPv6=C2=A0=C2=A0 prefix.=C2=A0=C2=A0 This prefix is retrieved from the NAT external IPv4 address.=C2=A0 A part from providing the prefix, NAT also encapsulates IPv6 packets in IPv4 for transport to oth= er 6to4 nodes or relays. This method=C2=A0=C2=A0 gives=C2=A0=C2=A0 a=C2=A0=C2=A0 possibility=C2=A0=C2=A0 for=C2=A0=C2=A0 communication=C2=A0=C2=A0 without problems between an IPv6 = node=C2=A0 using IPsec and=C2=A0 other nodes inside the IPv6 or 6 to 4 area= .

Unfortunately, 6to4 is not universally usable. It= is an appropriate solution where a single NAT separates a client and the VPN gateway but it cannot be used where multiple NATs=C2=A0=C2=A0 are=C2=A0=C2=A0 deployed=C2=A0=C2=A0 <= /span>between=C2=A0=C2=A0 client=C2=A0=C2=A0 = and=C2=A0=C2=A0 VPN=C2=A0=C2=A0 gateway. Reason for this is that forming of men= tioned IPv6 prefix requires the assignment of a routable IPv4 address to the NAT. Peers that support IPv6 need a little upgrade to be 6to4compatible,=C2=A0=C2=A0 while=C2=A0=C2=A0 NATs=C2=A0=C2=A0 require=C2=A0=C2=A0 <= /span>many=C2=A0=C2=A0 extensions=C2=A0=C2= =A0 to support 6 to 4.=C2=A0
=

On Tue, Mar 1, 20= 16 at 9:03 PM, Waltermire, David A. (Fed) <david.waltermire@nist.g= ov> wrote:
All:

With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe th= e draft is shaping up nicely, but needs additional review. To that end, thi= s message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-dd= os-protection-04.

The version to be reviewed is htt= ps://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt.

Please send your comments, questions, and edit proposals to the WG mail lis= t until March 18, 2015.=C2=A0 If you believe that the document is ready to = be submitted to the IESG for consideration as a Standards Track RFC please = send a short message stating this.

Best Regards,
Dave

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



--
Best Regards=C2=A0

Dr. Karan Verma=C2=A0
Assistant Professor=C2=A0=C2=A0
Computer Science and Engineering Dept.
Central University Rajasthan, India= =C2=A0
Website:=C2=A0www.drkaranverma.com
<= /div>
Phone: +917568169258
--001a11c349ce98ecaf052d349493-- From nobody Fri Mar 4 03:14:00 2016 Return-Path: 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 DC8FB1B36C0 for ; Fri, 4 Mar 2016 03:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[SPF_NEUTRAL=0.652] 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 JWloP7FF_QPl for ; Fri, 4 Mar 2016 03:13:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 BE9261B36BE for ; Fri, 4 Mar 2016 03:13:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u24B2wng026333 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Mar 2016 13:02:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u24B2vBg023850; Fri, 4 Mar 2016 13:02:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22233.27489.709920.963993@fireball.acr.fi> Date: Fri, 4 Mar 2016 13:02:57 +0200 From: Tero Kivinen To: "Paul Hoffman" In-Reply-To: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: Cc: IPsecME WG Subject: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 11:13:59 -0000 Paul Hoffman writes: > Greetings. We need to update our charter to reflect our current and > expected work. Dave and I propose the following text. Please let us know > within the next week if you have suggestions for changes. Should we add something about making the IKEv2 resistant to QC based attacks? Btw, looking at the latest attacks against TLS using SSLv2, the IKEv1 parts of the IPsec implementations are starting to scare me. I mean there is lots of old code there, that is not really updated anymore as the IKEv1 is obsoleted, and that code can be used to attack IPsec implementations. We have some customers asking about the DoS attacks IKEv1 using IKEv1 server as packet reflektor, then there is the sloth attack which worked much better against IKEv1 because it used MD5 etc. The problem is that lots of people are still using IKEv1, and there is not really good push away from it. I think it would be good idea to give bit more push to that, i.e., perhaps having draft-ietf-ipsecme-ikev1-diediediediedie (sslv2 and des only needed 3 dies, but IKEv1 is such zombie, that I do not think that killing it 3 times is enough :-) explaining why implementations should not use IKEv1. This is of course will not really change anything, but at least I could use it here in to convince customers that they need to move away from IKEv1, and perhaps it would wake up some implementors who only have IKEv1 in their implementations. Perhaps it could even provide some kind of transition plan: Stop using IKEv1 as default by now, disable automatic fallback by 2017 and require manual configuration to use it, and remove the support of IKEv1 completely from implemenations by 2020. -- kivinen@iki.fi From nobody Fri Mar 4 07:16:05 2016 Return-Path: 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 C3A1D1A1B59 for ; Fri, 4 Mar 2016 07:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 bkpDFkfMLQMr for ; Fri, 4 Mar 2016 07:16:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B9A771A1B13 for ; Fri, 4 Mar 2016 07:16:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qGt1W4hHqz38y; Fri, 4 Mar 2016 16:15:59 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RuZpoRvM2tXv; Fri, 4 Mar 2016 16:15:57 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 4 Mar 2016 16:15:57 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 84478603BBA1; Fri, 4 Mar 2016 10:15:51 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 84478603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 82C7CDA52A; Fri, 4 Mar 2016 10:15:51 -0500 (EST) Date: Fri, 4 Mar 2016 10:15:51 -0500 (EST) From: Paul Wouters To: "Dr. Karan Verma" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: ipsec@ietf.org, "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:16:03 -0000 On Fri, 4 Mar 2016, Dr. Karan Verma wrote: [ Did this go way of-topic? This does not relate to DDOS at all? ] > 1. The root CA certificate corresponding to the server certificate must be installed on the client computers in the > Trusted Root Certification Authorities per-computer certificate store. The client computer must be able to validate > the server certificate as being signed by a trusted root CA. Unless other AUTH mechanisms are used? > 2. If I keep my user and server key to a 2048-bit one it appears to be fine. You are lucky. 2048 bit certificates regularly cause fragmentation. > There's an RFC for this and support on recent Strong swan releases but the client has to ask for it during initial > negotiation and the BB10 client does not.  The result is that longer (and more-secure) keys won't work -- if you have > either a 4096-bit server certificate or a 4096-bit user cert the VPN will not come up. Yes, strongswan, libreswan and even iOS I think support fragmentation for IKEv2. >  3. First, we have incompatibility between IPsec AH and NAT.   This   is   because   AH   header   incorporates   > the   IP source   and   destination   addresses   in the keyed message integrity check and therefore NAT will > invalidate message integrity check by changing address fields. This makes A unusable in the presence of NAT devices. > ESP doesn't have this problem because it doesn't incorporate the IP header inits keyed message integrity check, so > changes in IP header will not conflict with ESP's integrity protection. You should not use AH. Use ESP_NULL instead in Tunnel Mode. > A more serious problem that affects both AH and ESP is incompatibility between   transport   layer   checksums   and > NAT. This problem occurs with AH and ESP in transport mode. Don't use Transport Mode. The few bytes gained are not worth the hassle. > There is also incompatibility between IKEv2 address identifiers   and   NAT.   Some   phases   of   IKEv2   use   IP > addresses as identifiers. Modification of these addresses through NAT will cause mismatch between identifiers and the > addresses in the IP header. The solution to this problem might   be   the   use   of   user   IDs   or   FQDNs   > that   are independent of IP addresses. I dont understand this at all. For any incoming IKE request that is not an IKE_INIT request, you have the SPI numbers that uniquely identify the IKE SA to match. In IKE_AUTH you are told the AUTH method to use, which can be anything. Outside of IKE_INIT and IKE_AUTH you are already authenticated and have your SPI's to match your connection. > IKE   protocol   requires   use   of   fixed   source   and destination   > ports.   This   also   causes   incompatibility with NAT. One possible scenario that might cause problems is when > multiple hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same responder. Mechanism is needed to > allow the NAPT to DE multiplex the incoming IKE   packets   from   responder. The NAT box will assign a different outgoing port for the second client trying to use port 4500 as outgoing source port. There is no problem. >   This   is   typically accomplished by > translating the IKE UDP source port on outbound   packets   from   initiator.   Because   of   that responders   > must   be   able   to   accept   IKE   traffic   from   a various  source  ports   (other  than  500   on  which  is  > IKE running) You are mixing up source port and destination port here. IKE daemons only need to listen on port 500 and 4500. And they should accept any port for the incoming IKE packets. > , and must reply to that port. The somewhat similar problem, but in it's own category, are the > incompatibilities between overlapping SPD entries when using NAT. We have a draft for that we will be updating soon. But you can also work locally on this. For example on linux you can add MARKing to the packet and have two identical SPD's that only differ by the mark. That means you can receive and reply conflicting SPDs fine, except you cannot initiate traffic to one specific SPD unless you manually mark your packet. >   There are situations when responder could send > packets down the wrong IPsec SA because of overlapping   SPD   entries. That would be an implementation bug.    This   could   happen   when initiating > hosts behind NAT use their source IP addresses in Phase 2 identifiers. I think you refer to two machines on 192.168.1.1 behind two different NAT routers? There should not be a problem but again you will need to use our natt draft lik approach or MARKing of some kind. Another problem between ESP  and NAT   lies  > in  thein compatibility   between   IPsec   SPI   selection   and   NAT. Since IPsec ESP traffic is encrypted, only > way for NATs to know how to demultiplex incoming packets is to inspect information’s in the IP and ESP header. These NAT's don't need to demultiplex anything. They just need to conntrack the local IP's and ports they assigned, and return reply traffic appropriately. This has no relation whatsoever to the packets. Of course this uses ESPinUDP. > information’s are usually destination IP address, IPsec SPI and security protocol (every SA is uniquely determined by > this three elements). Because of independent selection of incoming and outgoing SPIs it is possible that the NAT will > deliver the incoming IPsec packets to the wrong place when two hosts behind the NAT attempt to create IPsec SAs at the No that is not possible unless you have a broken implementation. Paul From nobody Fri Mar 4 07:29:22 2016 Return-Path: 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 A41C81A1BF4 for ; Fri, 4 Mar 2016 07:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 79DGetXurB3K for ; Fri, 4 Mar 2016 07:29:19 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 991591A1BF1 for ; Fri, 4 Mar 2016 07:29:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qGtJt090sz7B7; Fri, 4 Mar 2016 16:29:18 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id j11QMmmsdiqP; Fri, 4 Mar 2016 16:29:16 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 4 Mar 2016 16:29:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7AEB9603BBA1; Fri, 4 Mar 2016 10:29:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 7AEB9603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7974EDA52A; Fri, 4 Mar 2016 10:29:15 -0500 (EST) Date: Fri, 4 Mar 2016 10:29:15 -0500 (EST) From: Paul Wouters To: "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:29:20 -0000 > On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) wrote: > All: > > With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe the draft is shaping up nicely, > but needs additional review. To that end, this message starts a Working Group Last Call (WGLC) for > draft-ietf-ipsecme-ddos-protection-04. > > The version to be reviewed is https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. > > Please send your comments, questions, and edit proposals to the WG mail list until March 18, 2015.  If you > believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC > please send a short message stating this. I think the document is well written with respect to DDOS. I like everything except the puzzles. It seems a lot of complexity for no gain, especially with the problem being that botnets are better at puzzle solving then mobile phones who want to not drain their batteries. I would prefer this document to proceed without the puzzles, but I won't object to it if it remains in the document. As an implementor, it would be extremely unlikely that I would implement puzzles. Recently, I also thought about amplification attacks, which is not covered by the document. For instance, legitimate clients could pad their IKE_INIT Request as a way to tell the responder they are not just using the responder to amplify a DDOS attack. I am thinking of making that the default for some Opportunistic IPsec so it cannot be abused for amplification. I'd like to see that added to the draft if possible. Or if this document would not proceed, I would be tempted to write a draft for this idea. Paul From nobody Fri Mar 4 07:40:54 2016 Return-Path: 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 D1FA31A2182 for ; Fri, 4 Mar 2016 07:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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=-0.001, 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 4lU_-0wI9XFt for ; Fri, 4 Mar 2016 07:40:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6FE1A1EEE for ; Fri, 4 Mar 2016 07:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37520; q=dns/txt; s=iport; t=1457106045; x=1458315645; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PEAtvG1V7nh/esXORhJMPUK4xYNPlCjEjEEGm32TYVg=; b=R8txuTFdvceq38d/f19G3rhA9pJ5PsPESFT2frlArLTK+bk+/mxOPRlj f9yQ4MtRJ/Isgo1mfKSO3hcgTEw5njFUblZX2nKTsLDdEjuVivmtCYyH9 KVVDnL5SNJ8mxh5Ko2ICDIFEkfUVOrWRkBq9gMLacbyeKolrCTRynmT4X M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0BQByq9lW/4MNJK1UCYJuTFJtBrpCg?= =?us-ascii?q?WYDFwEJhW4CgTQ5EwEBAQEBAQFkJ4RBAQEBBAEBASpBGwIBCA4DBAEBIQEGByE?= =?us-ascii?q?GCxQJCAEBBAESCBMEh24DEg65Gg2ENAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEh?= =?us-ascii?q?heEPII8gVQDDkUJhAQFiDWKQ4QpAYtygW6PAIcKh0cBIQFAggEDGYFIaodzPX4?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos; i="5.22,536,1449532800"; d="scan'208,217"; a="77406866" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2016 15:40:44 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u24FeiU1016409 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 15:40:44 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 09:40:43 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 09:40:43 -0600 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: [IPsec] draft-fluhrer-qr-ikev2-01 Thread-Index: AdFrYV92xfNPMN/lQHOXoduZDaDkowAVQTwXApzGupA= Date: Fri, 4 Mar 2016 15:40:43 +0000 Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <81FF76AD3936477D913A27BED694E464@buildpc> In-Reply-To: <81FF76AD3936477D913A27BED694E464@buildpc> 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: [10.98.2.61] Content-Type: multipart/alternative; boundary="_000_d5594fbaea6648309c9bb02db3e37b67XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:40:52 -0000 --_000_d5594fbaea6648309c9bb02db3e37b67XCHRCD006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Valery Smyslov [mailto:svanru@gmail.com] Sent: Saturday, February 20, 2016 3:12 AM To: Scott Fluhrer (sfluhrer); ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 Hi Scott, thank you for issuing a new version of the draft that addresses most of my = comments on -00 version. However I still have some concerns. I'm not happy with the way algorithm ag= ility support is added into the draft. Currently the draft specifies PPK Indicator Algorithm as a 4 bytes long int= eger with a single defined value of 1 (AES256_SHA256). This definition does imply the need for= new registry since more algorithms would be specified. I don't see any compelli= ng reason to add a new registry, since the existing registries can be reused. I'd propose the following way to support algorithm agility. When the responder receives the initial request with PPK_REQUEST notificati= on, it parses SA payload collecting all PRF type transforms. The result is the list of PR= Fs the initiator supports. The responder picks the most preferred PRF from the list and retu= rns its value (as defined in the IKEv2 registry "Transform Type 2 - Pseudo-rand= om Function Transform IDs") as PPK Indicator algorithm in PPK_ENCODE notification. The PPK indicator is= computed using this PRF as foolws: ppk_indicator =3D PRF(PRF(ppk, "A"), ppk_indicator_input) This proposal has the following advantages. 1. Reusing existing IKEv2 registry 2. Better interoperability, since the PRF transform is mandatory in the SA = payload in IKEv2 and the responder can always be sure that the chosen PRF is su= pported by the initiator. With the current proposal the situation is possible w= hen the initiator includes, for example, only AEAD transforms in SA payload= . In this case even AEAD transform is (for example) AES based, there is n= o guarantee that plain AES encryption is also supported by the initiator. 3. The current PPK Indicator Algorithm field combines 2 algorithms - encryp= tion and prf. Actually, it doesn't - it only implements the "PPK hint" algorithm. Once more algorithms are supported as PPK indicator the size of the registry will be grown quickly since every new prf will be combi= ned with every new cipher (yes, it can be limited by combining only selected prfs with only selected ciphers, but that would reduce interop= erability). I would personally be surprised if there are any more algorithms added to t= he registry. The current algorithm works quite well, if we believe that AE= S is even slightly secure. The only reason I could see if someone asked fo= r something new is if they had issues actually implementing AES. This would make the idea of precomputing ppk indicators on responder less efficient (you may easily precompute the whole ppk database using = few popular PRFs, but if these PRFs are combined with ciphers - the resulting number of their combinations could become too big). With my idea, if you support only one PPK indicator algorithm, you need to = precompute each PPK once (if the server fixes the PPK indicator input). Wi= th your idea, you'd need to redo it for every PRF you support. How is this= an advantage for your idea? I see the only disadvantage of this proposal. As you wrote you specifically used combination of encryption and PRF since AES is supported in hardware on some CPUs and thus gives some performance advantages over PRF-only scheme. I don't think it is a compelling argument. Actually, I would argue that it is. One complaint I've heard is that this = would require the server to scan through its list of PPK's for every sessio= n it gets. The current draft allows a server to reissue PPK indicator inpu= ts to reduce this impact; however we would prefer servers to reissue PPK in= dicator inputs are rarely as possible. Making the evaluation of the PPK al= gorithm cheaper encourages implementations to do this. It reflects only the current situation in the industry and may change over time. It may, but likely won't. Intel has announced hardware support for acceler= ating SHA-1 and SHA-256; however I believe that even with that support, one= AES-NI evaluation of AES-256 will be faster than two evaluations of the bl= ock compression of either SHA-1 or SHA-256 (assuming the PRF is either HMAC= -SHA1 or HMAC-SHA256) I don't think the protocol should be based on such shaky grounds. Am I missing something? >From where I stand, it would appear that the main advantage of your proposa= l is "we won't have to ask IANA for another registry". Am I missing someth= ing? Few editorial issues: 1. Abstract No point at the end of the abstract. 2. Section 1 [The general idea is that we add an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2.] s/in addition/an addition ? 3. IANA Considerations section is missing. Regards, Valery Smyslov. Last year, NSA made an announcement about how to deal with the potentiality= of someone developing a Quantum Computer; (https://www.nsa.gov/ia/programs= /suiteb_cryptography/). Among their recommendations was the advice that: "CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant = implementations of the IKE standard (IKEv1) together with large, high-entro= py, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the o= nly version of the IKE standard that leverages symmetric pre-shared keys in= a manner that may achieve quantum resistant confidentiality. The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in th= e preshared key into the KDF function (along with the (EC)DH shared secret)= ; hence if the preshared key was strong, then Shor's algorithm (which can r= ecover the (EC)DH shared secret) is not enough to recover the negotiated ke= ys. Now, we don't want people to migrate back to an obsolete version of the pro= tocol; hence we've devised a way to strengthen IKEv2 the same way. It was considered important to minimize the changes made to IKEv2. From a = cryptographical prespective, the only change we make is that we modify the = nonces that we present to the KDF. By keeping the cryptographical changes = minimal, we reduce the risk of accidentally introducing a weakness. Like IKEv1, this solution assumes that the initiator and the responder shar= e a secret string (called a PPK in the draft). However, unlike IKEv1, that= is not the only authentication that's in the system. We leave the existin= g authentication methods in place, and add this in addition. One thing that was a source of complexity was that we did not want to assum= e that every system had the same PPK; that instead that systems would want = a pairwise PPK. However, if a responder configured its PPK on a per-peer b= asis, and didn't learn the peer until after an IKEv2 tunnel has been establ= ished, that would mean that the responder would need to know the PPK before= it officially learned the peer. To solve this, we added the PPK_REQUEST/P= PK_ENCODE notifications to give the responder a hint about which PPK to use= (without leaking the identity to third parties). Would anyone be willing to review this draft? I believe that we have a nee= d for such a solution. ________________________________ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_d5594fbaea6648309c9bb02db3e37b67XCHRCD006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Valery S= myslov [mailto:svanru@gmail.com]
Sent: Saturday, February 20, 2016 3:12 AM
To: Scott Fluhrer (sfluhrer); ipsec@ietf.org
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01

 

Hi Scott,

 

thank you for issuing a new version = of the draft that addresses most of my comments on -00 version.

 

However I still have some concerns. = I'm not happy with the way algorithm agility support is added

into the draft.

 

Currently the draft specifies PPK In= dicator Algorithm as a 4 bytes long integer with a single

defined value of 1 (AES256_SHA256). = This definition does imply the need for new

registry since more algorithms would= be specified. I don't see any compelling reason to add a new registry= ,

since the existing registries can be= reused. 

 

I'd propose the following way to sup= port algorithm agility.

 

When the responder receives the init= ial request with PPK_REQUEST notification, it parses=

SA payload collecting all = PRF type transforms. The result is the list of PRFs the initiator

supports. The responder picks the mo= st preferred PRF from the list and returns

its value (as defined in the IKEv2 r= egistry "Transform Type 2 - Pseudo-random Function Transform IDs"= ) 

as PPK Indicator algorithm in PPK_EN= CODE notification. The PPK indicator is computed

using this PRF as foolws:

 

ppk_indicator =3D PRF(PRF(ppk, "= ;A"), ppk_indicator_input)

 

This proposal has the following adva= ntages.

1. Reusing existing IKEv2 registry

2. Better interoperability, sin= ce the PRF transform is mandatory in the SA payload<= o:p>

    in IKEv2 and the = responder can always be sure that the chosen PRF is supported

    by the initiator.= With the current proposal the situation is possible when

    the initiator inc= ludes, for example, only AEAD transforms in SA payload.

    In this case even= AEAD transform is (for example) AES based, there is no guarantee

    that plain AES en= cryption is also supported by the initiator.

3. The current PPK Indicator Algorit= hm field combines 2 algorithms - encryption

    and prf.

Actually, it doesnR= 17;t – it only implements the “PPK hint” algorithm.<= /o:p>

 

Once more algorithms are supported a= s PPK indicator the size

    of the registry w= ill be grown quickly since every new prf will be combined

    with every new ci= pher (yes, it can be limited by combining only<= /o:p>

    selected prfs wit= h only selected ciphers, but that would reduce interoperability).
I would personally be surprised= if there are any more algorithms added to the registry.  The current = algorithm works quite well, if we believe that AES is even slightly secure.=   The only reason I could see if someone asked for something new is if they had issues actually implementing AES.

 

    This would make t= he idea of precomputing ppk indicators on responder<= o:p>

    less efficient (y= ou may easily precompute the whole ppk database using few<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif"">

    popular PRFs, but= if these PRFs are combined with ciphers -

    the resulting num= ber of their combinations could become too big).

With my idea, if you s= upport only one PPK indicator algorithm, you need to precompute each PPK on= ce (if the server fixes the PPK indicator input).  With your idea, you= ’d need to redo it for every PRF you support.  How is this an advantage for your idea?

 

 

I see the only disadvantage of this = proposal. As you wrote you specifically

used combination of encryption and P= RF since AES is supported in hardware

on some CPUs and thus gives some per= formance advantages over PRF-only<= /p>

scheme. I don't think it is a c= ompelling argument.<= /p>

 

Actually, I would argu= e that it is.  One complaint I’ve heard is that this would requi= re the server to scan through its list of PPK’s for every session it = gets.  The current draft allows a server to reissue PPK indicator inputs to reduce this impact; however we would prefer servers to= reissue PPK indicator inputs are rarely as possible.  Making the eval= uation of the PPK algorithm cheaper encourages implementations to do this.<= o:p>

 

It reflects only the current<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",&quo= t;serif"">

situation in the industry and may ch= ange over time.

 

It may, but likely won= ’t.  Intel has announced hardware support for accelerating SHA-1= and SHA-256; however I believe that even with that support, one AES-NI eva= luation of AES-256 will be faster than two evaluations of the block compression of either SHA-1 or SHA-256 (assuming the PRF is e= ither HMAC-SHA1 or HMAC-SHA256)

 

I don't think the protocol

should be based on such shaky ground= s. Am I missing something?

 

From where I stand, it= would appear that the main advantage of your proposal is “we wonR= 17;t have to ask IANA for another registry”.  Am I missing somet= hing?

 

 

Few editorial issues:

 

1. Abstract

    No point at the e= nd of the abstract.

 

2. Section 1<= o:p>

   [The general idea is th= at we add an additional secret that is shared
   between the initiator and the responder; this secret is in add= ition
   to the authentication method that is already provided within I= KEv2.]

    s/in addition/an = addition ?

 

3. IANA Considerations section is mi= ssing.

 

Regards,=

Valery Smyslov. 

 

 

 

Last year, NSA made an announcement about how to dea= l with the potentiality of someone developing a Quantum Computer; (https://www.nsa.g= ov/ia/programs/suiteb_cryptography/).  Among their recommendations was the advice that:

 

“CSfC deployments i= nvolving an IKE/IPsec layer may use RFC 2409-conformant implementations of = the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys= and the AES-256 encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-= shared keys in a manner that may achieve quantum resistant confidentiality.=

 

The reason they gave this advise was the IKEv1, unli= ke IKEv2, stirred in the preshared key into the KDF function (along with th= e (EC)DH shared secret); hence if the preshared key was strong, then Shor&#= 8217;s algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys.

 

Now, we don’t want people to migrate back to a= n obsolete version of the protocol; hence we’ve devised a way to stre= ngthen IKEv2 the same way.

 

It was considered important to minimize the changes = made to IKEv2.  From a cryptographical prespective, the only change we= make is that we modify the nonces that we present to the KDF.  By kee= ping the cryptographical changes minimal, we reduce the risk of accidentally introducing a weakness.

 

Like IKEv1, this solution assumes that the initiator= and the responder share a secret string (called a PPK in the draft). = However, unlike IKEv1, that is not the only authentication that’s in= the system.  We leave the existing authentication methods in place, and add this in addition.

 

One thing that was a source of complexity was that w= e did not want to assume that every system had the same PPK; that instead t= hat systems would want a pairwise PPK.  However, if a responder config= ured its PPK on a per-peer basis, and didn’t learn the peer until after an IKEv2 tunnel has been established, that woul= d mean that the responder would need to know the PPK before it officially l= earned the peer.  To solve this, we added the PPK_REQUEST/PPK_ENCODE n= otifications to give the responder a hint about which PPK to use (without leaking the identity to third parties= ).

 

 

Would anyone be willing to review this draft?  = I believe that we have a need for such a solution.

____________________________________= ___________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_d5594fbaea6648309c9bb02db3e37b67XCHRCD006ciscocom_-- From nobody Fri Mar 4 09:02:10 2016 Return-Path: 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 5B8761A1AA9 for ; Fri, 4 Mar 2016 09:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 xnGKDphLflBT for ; Fri, 4 Mar 2016 09:02:06 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B371A1AA7 for ; Fri, 4 Mar 2016 09:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457110926; x=2321024526; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dFE4rlIUfeUweCG6b9maWBDqes/sK45URuulTVnNie0=; b=Iq7VkqW4KWBgaDwxhkOp3gWRaD49nty4+jNvuX5b/FjCtgN/hhAFMavy6Egs/kuj /i3v/0IrzTZRaVdEktdec6ZmtXZ5oxxrx7ku70KAbtXjXcqSccXqBYdnpyee1XRi ctRC04ksbY3KpyJGL4xuDYQGoHlHwfCoOaseNmNc/tpyqGhnnQV0JKgIt0WWaREz ZRsHNgU+X5WcvRA+BzqRjfAnRmpXTnRUSE0BPUojuf+j4wAQKwIcit+rIhmlqVZa 6M1ZXEEiirxtEMvXqAJLRQAerUgzxCd38U2OdM7QSQ73PK6kOFw5H/wW+w3uTNsv PppiVw3ffmhH75/iJcLyfQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 1A.4C.27179.D8FB9D65; Fri, 4 Mar 2016 09:02:06 -0800 (PST) X-AuditID: 11973e15-f79686d000006a2b-63-56d9bf8ddbfc Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 48.2D.18091.D8FB9D65; Fri, 4 Mar 2016 09:02:05 -0800 (PST) Received: from [17.153.62.167] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3I009GEXZFJW10@chive.apple.com> for ipsec@ietf.org; Fri, 04 Mar 2016 09:02:04 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) From: Tommy Pauly In-reply-to: Date: Fri, 04 Mar 2016 09:02:02 -0800 Content-transfer-encoding: quoted-printable Message-id: References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FAYpdu3/2aYwdKPnBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpXdjxgLXstX7NnUz9jAuEWyi5GTQ0LARGLbu68sELaYxIV7 69m6GLk4hAT2MkqcbXzP2sXIAVb0bkcMRHwak8TPI9ehij4xStyedYwdpEhYQEJi855EEJNZ QF1iypRcEJNXQF/i15lwkPHCAk4SN1Y+ZwKx2QRUJI5/28AMYnMKOEq0nuoFs1kEVCVufHzL CGIzC7hLLN+6kh3C1pZ48u4CK4jNK2Aj8eTxcbC4kMAdRon9/+RBbBGg+IXJD1ghXpGVuHP8 NAvIlRICK9gkDn+czTqBUWQWwnWzEK6bhWTDAkbmVYxCuYmZObqZeWZ6iQUFOal6yfm5mxhB YT3dTnQH45lVVocYBTgYlXh4bzRcDxNiTSwrrsw9xCjNwaIkzrtVCCgkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qB8fhfG1PX7OgcjgsfuC03qqrdsDuf+Oe494eDkocXst4T3FafZsjhyDtz 9zkF65Utb0OYVTfqHz0zfZo3/yJTVTU5pxV5se5fw32v/zhdX3CpU+/GCi1fg+CZl2wN/grt XnFrZcCUdVLGNztXXIp3a16VERvz5kD28gkc01PsCt4XhRXlbpvDr8RSnJFoqMVcVJwIAHH5 8IlMAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUi2FDMr9u7/2aYwZ8/Zhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpXdjxgLXstX7NnUz9jAuEWyi5GDQ0LAROLdjpguRk4gU0zi wr31bF2MXBxCAtOYJH4euQ7lfGKUuD3rGDtIg7CAhMTmPYkgJrOAusSUKbkgJq+AvsSvM+Eg Y4QFnCRurHzOBGKzCahIHP+2gRnE5hRwlGg91QtmswioStz4+JYRxGYWcJdYvnUlO4StLfHk 3QVWEJtXwEbiyePjYHEhgTuMEvv/yYPYIkDxC5MfsEKcLCtx5/hplgmMgrMQDpqFcNAsJEMX MDKvYhQoSs1JrDTTSywoyEnVS87P3cQIDsPCqB2MDcutDjEKcDAq8fDeaLgeJsSaWFZcmXuI UYKDWUmEd+3um2FCvCmJlVWpRfnxRaU5qcWHGJOBXpnILCWanA+MkbySeEMTEwMTY2MzY2Nz E3PShJXEec1OXA0TEkhPLEnNTk0tSC2C2cLEwSnVwNiQKz9pu+iFm6oa11VsdXzvzFPX2mZ8 LndaOmfmLIeizT4z+J7Zr+TvfyDb5zJ1+Z9P+3eENb3SvG0WY2Y/a/nhprbL5f8Z/+9zXLlI 6W7B46bvO9csZXFTWuhzXHTyemGL3Lf3PvwwMLrCliDtk9X9pe+UqECsqP1y0x95LWU9m6wb 2ZViJyixFGckGmoxFxUnAgCOWkARhwIAAA== Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:02:08 -0000 Hello Dave, I tend to agree with Paul that I find it unlikely, from an = implementor=E2=80=99s standpoint, that many Initiators will choose to = implement the puzzle logic, especially ones that are running on mobile = devices. It is unlikely that the phones will be able to solve the = puzzles quickly enough to beat out botnets, and it would be hard to = justify the battery consumption necessary. That being said, the document = does a very good job of explaining the problem space, and the other = parts of its solution (rate-limiting and suggesting session resumption) = make good sense. Perhaps there can be more focus on how a responder can = best protect itself if indeed the majority of its clients do not support = puzzles? One question on section 7.1.2: If the received message contains a PUZZLE notification and doesn't contain a COOKIE notification, then this message is malformed because it requests to solve the puzzle, but doesn't provide enough information to do it. In this case the Initiator SHOULD resend IKE_SA_INIT request. If this situation repeats several times, then it means that something is wrong and the IKE SA cannot be established. I am concerned that the suggestion for the initiator reacting to = malformed IKE_SA_INIT packets is to send more traffic to the responder. = The responder should not legitimately send a PUZZLE notification without = a COOKIE notification, since this would be invalid. If the initiator = sees this, it can either assume that (a) the responder=E2=80=99s = implementation is out of spec, or (b) some malicious third party is = deliberately modifying the unencrypted packet. In the first case, trying = to send the IKE_SA_INIT again would be in vain; in the second case, we = have provided a way for a third party to cause initiators to send more = traffic to the responder, thus providing an attack vector. What are your = thoughts on this? Thanks, Tommy > On Mar 4, 2016, at 7:29 AM, Paul Wouters wrote: >=20 >> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) = wrote: >> All: >>=20 >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I = believe the draft is shaping up nicely, >> but needs additional review. To that end, this message starts a = Working Group Last Call (WGLC) for >> draft-ietf-ipsecme-ddos-protection-04. >>=20 >> The version to be reviewed is = https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. >>=20 >> Please send your comments, questions, and edit proposals to the = WG mail list until March 18, 2015. If you >> believe that the document is ready to be submitted to the IESG = for consideration as a Standards Track RFC >> please send a short message stating this. >=20 > I think the document is well written with respect to DDOS. I like > everything except the puzzles. It seems a lot of complexity for > no gain, especially with the problem being that botnets are better > at puzzle solving then mobile phones who want to not drain their > batteries. I would prefer this document to proceed without the > puzzles, but I won't object to it if it remains in the document. > As an implementor, it would be extremely unlikely that I would > implement puzzles. >=20 > Recently, I also thought about amplification attacks, which is not > covered by the document. For instance, legitimate clients could pad > their IKE_INIT Request as a way to tell the responder they are not = just > using the responder to amplify a DDOS attack. I am thinking of making > that the default for some Opportunistic IPsec so it cannot be abused = for > amplification. I'd like to see that added to the draft if possible. Or > if this document would not proceed, I would be tempted to write a = draft > for this idea. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 4 09:05:49 2016 Return-Path: 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 2397C1A1AA7 for ; Fri, 4 Mar 2016 09:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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=-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 cX7bFkE8CZvA for ; Fri, 4 Mar 2016 09:05:46 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5971A1A58 for ; Fri, 4 Mar 2016 09:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457111145; x=2321024745; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=grvJpvkIpzd0TBQUcNCxJAKo5NJseOrqg2aZf2ytVgo=; b=MtAp48vtWINJTh9vXbJJx+GFDcCPQmXYNItq4Wv8I3Wlq1JLJaBEwxSR5A6dLp/G 2XR4Yn21k+iB8lPVZzyj6qlOZlpaS9IiOc+rvjUM2vGMPHAMezO43hWK0klt+Tbr MU8AxosKe8zVe3zD/8+PTI3nAgHRKRV1AT+ZLIGQubMeo/JklteLG8FWPrwogzY0 JwquOcrmF8xvXenfaz/tehKbcb4CLbcq55KLGsYcdJ/ziIkhsbkrKerpOtuwgINp /FhnQ8Or210CQoWGZEipSYqdzRqUUIpSdxnAWc6OraH73Tki5XQU/r/tL2bdivBQ UB+cxiIFju6cP7SLpvVDmg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 8D.76.25552.960C9D65; Fri, 4 Mar 2016 09:05:45 -0800 (PST) X-AuditID: 11973e16-f79bc6d0000063d0-4d-56d9c069b8eb Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 4C.10.18091.960C9D65; Fri, 4 Mar 2016 09:05:45 -0800 (PST) Received: from [17.153.62.167] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3I009KSY5KJW10@chive.apple.com> for ipsec@ietf.org; Fri, 04 Mar 2016 09:05:45 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) From: Tommy Pauly In-reply-to: Date: Fri, 04 Mar 2016 09:05:43 -0800 Content-transfer-encoding: quoted-printable Message-id: <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYpZt54GaYQUu3mcX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf7NJfaCP7IVXXd6WRoYN0l0MXJySAiYSHyYvYkJwhaTuHBv PVsXIxeHkMBeRombjW2MMEVfPn5ghEhMY5K41/SZFcL5xCjR9HsSexcjB4ewgITE5j2JICaz gLrElCm5ICavgL7ErzPhIGOEBawlVky+wQpiswmoSBz/toEZxOYUsJXYNvUBC0g5i4CqxPI3 0SBhZgFXiT1XnrNA2NoST95dYIWYaCPx7DxYp5BAnsSf23vAjhQRUJSYdOYRC8TBshJ3jp9m AblRQmAJm8ShVXfZJjCKzEK4bRbCbbOQLFjAyLyKUSg3MTNHNzPPXC+xoCAnVS85P3cTIyio p9uJ7WB8uMrqEKMAB6MSD++NhuthQqyJZcWVuYcYpTlYlMR5NwsBhQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDKFYpr8wpsrtAMk3lTlJNppVLoMFFf0si4++38iTp7sjP1tBl4G0++V5Sw 4Is4dJPpYLT4vrjkjg29fzea+DyftfDN224Nw10vxdV+fCp6p3TXQSvtQqijo3KUhbvc5eKn JV27E6W1wpa+3yMxZffS9skbp6qqcosqObHN6LA93h+sFchiq8RSnJFoqMVcVJwIALaGbPJL AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDMr5t54GaYQdcFA4v9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ybS+wFf2Qruu70sjQwbpLoYuTkkBAwkfjy8QMjhC0mceHe erYuRi4OIYFpTBL3mj6zQjifGCWafk9i72Lk4BAWkJDYvCcRxGQWUJeYMiUXxOQV0Jf4dSYc ZIywgLXEisk3WEFsNgEViePfNjCD2JwCthLbpj5gASlnEVCVWP4mGiTMLOAqsefKcxYIW1vi ybsLrBATbSSenQfrFBLIk/hzew/YkSICihKTzjxigThYVuLO8dMsExgFZyGcMwvhnFlIZi5g ZF7FKFCUmpNYaaaXWFCQk6qXnJ+7iREchIVROxgbllsdYhTgYFTi4b3RcD1MiDWxrLgy9xCj BAezkgjv2t03w4R4UxIrq1KL8uOLSnNSiw8xJgM9MpFZSjQ5HxgheSXxhiYmBibGxmbGxuYm 5qQJK4nzmp24GiYkkJ5YkpqdmlqQWgSzhYmDU6qBMasnZcURf06m+3IhrjLG2Sf/f+tNKt3G /+Xu8QIh244bguXWfycGaqetcozPaV33rG5KxP3qgNVc6tH3dh+INeuryldelcA15dQZB4Gg q5OyLtsxVS5mYkw65aK+8mrfsvtqU7fptwrZL1nF+a08ovHx4SMx92e7hC7KsVb/9IVL9qbK XuG7SizFGYmGWsxFxYkALbyjHoYCAAA= Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:05:48 -0000 I would also like to see the draft for TCP encapsulation added as an = item, since we=E2=80=99ve gotten a fair amount of support for it. For = the purposes of the charter, it may be good to have a broader = explanation of the goal=E2=80=94something to the effect that the working = group should focus on making sure that IKEv2 can be deployed more = universally by taking into account limitations of various networks. = Previous RFCs like IKE fragmentation have contributed to this; TCP = encapsulation tries to solve another set of problematic networks; and we = can imagine that there may be more to investigate, such as taking into = account the limitations and requirements of IoT networks, etc. Tommy > On Mar 1, 2016, at 12:32 PM, Paul Wouters wrote: >=20 > S/mostly//=20 >=20 > Add IKE over tcp and DNS extensions for ikev2? >=20 > Sent from my iPhone >=20 >> On Mar 1, 2016, at 11:18, Paul Hoffman wrote: >>=20 >> Greetings. We need to update our charter to reflect our current and = expected work. Dave and I propose the following text. Please let us know = within the next week if you have suggestions for changes. >>=20 >> --Paul Hoffman and Dave Waltermire >>=20 >>=20 >> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated = RFCs), >> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). = IPsec is >> widely deployed in VPN gateways, VPN remote access clients, and as a >> substrate for host-to-host, host-to-network, and network-to-network >> security. >>=20 >> The IPsec Maintenance and Extensions Working Group continues the work = of >> the earlier IPsec Working Group which was concluded in 2005. Its = purpose is >> to maintain the IPsec standard and to facilitate discussion of = clarifications, >> improvements, and extensions to IPsec, mostly to IKEv2. >> The working group also serves as a focus point for other IETF Working = Groups >> who use IPsec in their own protocols. >>=20 >> The current work items include: >>=20 >> IKEv2 contains the cookie mechanism to protect against denial of = service >> attacks. However this mechanism cannot protect an IKE end-point = (typically, >> a large gateway) from "distributed denial of service", a coordinated = attack by >> a large number of "bots". The working group will analyze the problem = and >> propose a solution, by offering best practices and potentially by = extending >> the protocol. >>=20 >> IKEv2 utilizes a number of cryptographic algorithms in order to = provide >> security services. To support interoperability a number of = mandatory-to- >> implement (MTI) algorithms are defined in RFC4307. There is interest = in >> updating the MTIs in >> RFC4307 based on new algorithms, changes to the understood security >> strength of existing algorithms, and the degree of adoption of = previously >> introduced algorithms. The group will revise RFC4307 proposing = updates to >> the MIT algorithms used by IKEv2 to address these changes. >>=20 >> There is interest in supporting Curve25519 and Curve448 for ephemeral = key >> exchange in the IKEv2 protocol. The group will extend the >> IKEv2 protocol to support key agreement using these curves and their >> related functions. >>=20 >> This charter will expire in August 2016. If the charter is not = updated before >> that time, the WG will be closed and any remaining documents revert = back to >> individual Internet-Drafts. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 4 09:33:01 2016 Return-Path: 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 4AFB41A1E0E for ; Fri, 4 Mar 2016 09:33:00 -0800 (PST) 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 h8Gfg5TpavXK for ; Fri, 4 Mar 2016 09:32:58 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E321A1E0B for ; Fri, 4 Mar 2016 09:32:58 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l68so866643wml.0 for ; Fri, 04 Mar 2016 09:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It9uNJB5QfhaVVHp+RYdlxpCC/TEi5jcmBBHyHGSMqc=; b=FI4THSBqxOMwE8cnE//71s3iR+uV6dhyCKraN7DWw8qGOfooJ0uPPPe8tLmz+NWcsu NjxTD+MS9YqmuJ9s54CxmNLOq9nk2rEEdz+JQKqlhnWUJR+nZs5yGE45hw0OXyJHCohk ZtRHybGqJ0x8oTTI4G2rZn5GeW+8C7qK8TrcDXfqpHDtQOlhJ9w2egCQ0NUWpait+AaJ 87+jp4VEffepGR7lihCifIzPapnW9wuBzHnZeuknUrLBvuhOowTJrMz3mwg/QZOgvneu /6CDmP+LCX1a3jfsrwJbKYFNjPzYOBCZ+w9AfrSeZstlso0+vLkYRLo0++gJgeHUYEd+ R6Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It9uNJB5QfhaVVHp+RYdlxpCC/TEi5jcmBBHyHGSMqc=; b=BUB0MGZskXgdXUflpKiLSMEMStlxWExaIG/TjGeV2KD/areraUxP/XrfBjBANTSRGc 3ac+bOD0o+Pnm3ewxvsMrNPVa2FeVH3Qyp3aH+GJRuWOXLWhywoRRzIM9bBsGe50E+ee MQD830pWf6SYwTTVAmir2G7baRI2kp19DYD/YDFEkATQZ3iXLFY8glKfICvETKDImARW 9qxEQedr9QmltIBgsGtny9aRui5c77HxIYJbNA3L8NgLxa3IrumNy00GZ2cvMekzbSdf D6iT5YteY1mXPeikm4mS1hO3NI4z33ccP4/Px6w2Phihu0GUblj5c++pi1n6Ucehg7mh FRpQ== X-Gm-Message-State: AD7BkJKdJmi0VOO3o3HL7Z9iULvOeD+9LMvI76V7pYobYuQTb7fniaOdZ/tsoLj9PGzLuA== X-Received: by 10.28.172.194 with SMTP id v185mr77322wme.21.1457112777113; Fri, 04 Mar 2016 09:32:57 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id jf6sm4388407wjb.2.2016.03.04.09.32.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Mar 2016 09:32:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Fri, 4 Mar 2016 19:32:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tommy Pauly X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:33:00 -0000 > On 4 Mar 2016, at 7:02 PM, Tommy Pauly wrote: >=20 > Hello Dave, >=20 > I tend to agree with Paul that I find it unlikely, from an = implementor=E2=80=99s standpoint, that many Initiators will choose to = implement the puzzle logic, especially ones that are running on mobile = devices. It is unlikely that the phones will be able to solve the = puzzles quickly enough to beat out botnets, and it would be hard to = justify the battery consumption necessary. That being said, the document = does a very good job of explaining the problem space, and the other = parts of its solution (rate-limiting and suggesting session resumption) = make good sense. Perhaps there can be more focus on how a responder can = best protect itself if indeed the majority of its clients do not support = puzzles? >=20 > One question on section 7.1.2: >=20 > If the received message contains a PUZZLE notification and doesn't > contain a COOKIE notification, then this message is malformed = because > it requests to solve the puzzle, but doesn't provide enough > information to do it. In this case the Initiator SHOULD resend > IKE_SA_INIT request. If this situation repeats several times, then > it means that something is wrong and the IKE SA cannot be > established. >=20 > I am concerned that the suggestion for the initiator reacting to = malformed IKE_SA_INIT packets is to send more traffic to the responder. = The responder should not legitimately send a PUZZLE notification without = a COOKIE notification, since this would be invalid. If the initiator = sees this, it can either assume that (a) the responder=E2=80=99s = implementation is out of spec, or (b) some malicious third party is = deliberately modifying the unencrypted packet. In the first case, trying = to send the IKE_SA_INIT again would be in vain; in the second case, we = have provided a way for a third party to cause initiators to send more = traffic to the responder, thus providing an attack vector. What are your = thoughts on this? A proper responder would not send a malformed packet. An attacker could = send a malformed response immediately after the initiator sends the = request. By the time the initiator gets the real responder=E2=80=99s = response, it has lost state.=20 That is why it is always a good idea (not just in this context) for the = initiator to ignore malformed responses until the timeout is reached. Yoav From nobody Fri Mar 4 09:35:40 2016 Return-Path: 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 2FD7A1A1EF1 for ; Fri, 4 Mar 2016 09:35:39 -0800 (PST) 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 PdIwVY9mz6Nk for ; Fri, 4 Mar 2016 09:35:37 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7BC1A1EFE for ; Fri, 4 Mar 2016 09:35:35 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id l68so963899wml.0 for ; Fri, 04 Mar 2016 09:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FIB3URbjiX3YEsVXAFTlCaEknZzXNQ19Bpnj3LQdcKs=; b=odw82BLFrsA8N49xMtkWWBcMwRfaIelRPNAxhqxOI7X4x5b2mnSpc4UTEw8sI54c0+ cXLQdWepQ/BG1IL80IOXg2Tx6mqWxx76WJK0zLHraMyrXbBtN2J3Vah7bvNQVxZFihrw 9O6sLVSTOHJdb0Bj3TYOBoLmGIpIWJY9DIV5thfdj3J8G4zujh6oKz/kmcb4poAjmqo+ hLVmImoAjpzveLmMl+b2jU/CZkA2HIeE2JJBHzvfdU668b6mlTAGOYIdk7gtD7uRWnmL goRAZRwH74qooPfXB02GkgwaEixps3TqCmIEcI9HN2TmTMhlTfI3hQYkC5mLOXCXtzPR mu0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FIB3URbjiX3YEsVXAFTlCaEknZzXNQ19Bpnj3LQdcKs=; b=BSjL6DRb2ZpJOLBbNW71PCeLNaUqw7V1VHRyypwa9YKKOTEPtmNubxv+wxtJkSq5f1 71okHnt3qbyJr8d77Utucn6i9GmlUbACSTx61oHZ/8WpqtyvGaKx1YdpvzC0+WlmmplJ wzMOhGvd8KOSj/lJwTBBDsmm4awK6EyVa4DdtrOqAL2XRsU3KL0VSzcohMwgQ3JsmQYg YPV0tMWCc5B4x9KXHTBkVphfnSpbvxxEW4l1Wqta1d3lGXu0XzY2kuIiyueBAeyS2wZj 4a181RBYb4SUF4SSHrs1VZ6Kf6Q+KdSn2olfLT6rpVACuh1XCjQeH1/k0/R+kxvGOM8c ye5w== X-Gm-Message-State: AD7BkJLbYZ2p5/5a6uqr3/IthXKlaFvhWpFB6FfUcr/GcFVz+5+RijxZHorGE4rNlugTbg== X-Received: by 10.194.71.135 with SMTP id v7mr10267645wju.135.1457112934188; Fri, 04 Mar 2016 09:35:34 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id p125sm79905wmd.16.2016.03.04.09.35.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Mar 2016 09:35:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> Date: Fri, 4 Mar 2016 19:35:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3112) Archived-At: Cc: IPsecME WG , Paul Wouters , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 17:35:39 -0000 +1=20 Speaking as an implementer, we have done something similar for our IKEv1 = clients, and would be happy to have something standards-based for IKEv2. I would be happy to see this work become an RFC. Yoav > On 4 Mar 2016, at 7:05 PM, Tommy Pauly wrote: >=20 > I would also like to see the draft for TCP encapsulation added as an = item, since we=E2=80=99ve gotten a fair amount of support for it. For = the purposes of the charter, it may be good to have a broader = explanation of the goal=E2=80=94something to the effect that the working = group should focus on making sure that IKEv2 can be deployed more = universally by taking into account limitations of various networks. = Previous RFCs like IKE fragmentation have contributed to this; TCP = encapsulation tries to solve another set of problematic networks; and we = can imagine that there may be more to investigate, such as taking into = account the limitations and requirements of IoT networks, etc. >=20 > Tommy >=20 >> On Mar 1, 2016, at 12:32 PM, Paul Wouters wrote: >>=20 >> S/mostly//=20 >>=20 >> Add IKE over tcp and DNS extensions for ikev2? >>=20 >> Sent from my iPhone >>=20 >>> On Mar 1, 2016, at 11:18, Paul Hoffman = wrote: >>>=20 >>> Greetings. We need to update our charter to reflect our current and = expected work. Dave and I propose the following text. Please let us know = within the next week if you have suggestions for changes. >>>=20 >>> --Paul Hoffman and Dave Waltermire >>>=20 >>>=20 >>> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated = RFCs), >>> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). = IPsec is >>> widely deployed in VPN gateways, VPN remote access clients, and as a >>> substrate for host-to-host, host-to-network, and network-to-network >>> security. >>>=20 >>> The IPsec Maintenance and Extensions Working Group continues the = work of >>> the earlier IPsec Working Group which was concluded in 2005. Its = purpose is >>> to maintain the IPsec standard and to facilitate discussion of = clarifications, >>> improvements, and extensions to IPsec, mostly to IKEv2. >>> The working group also serves as a focus point for other IETF = Working Groups >>> who use IPsec in their own protocols. >>>=20 >>> The current work items include: >>>=20 >>> IKEv2 contains the cookie mechanism to protect against denial of = service >>> attacks. However this mechanism cannot protect an IKE end-point = (typically, >>> a large gateway) from "distributed denial of service", a coordinated = attack by >>> a large number of "bots". The working group will analyze the problem = and >>> propose a solution, by offering best practices and potentially by = extending >>> the protocol. >>>=20 >>> IKEv2 utilizes a number of cryptographic algorithms in order to = provide >>> security services. To support interoperability a number of = mandatory-to- >>> implement (MTI) algorithms are defined in RFC4307. There is interest = in >>> updating the MTIs in >>> RFC4307 based on new algorithms, changes to the understood security >>> strength of existing algorithms, and the degree of adoption of = previously >>> introduced algorithms. The group will revise RFC4307 proposing = updates to >>> the MIT algorithms used by IKEv2 to address these changes. >>>=20 >>> There is interest in supporting Curve25519 and Curve448 for = ephemeral key >>> exchange in the IKEv2 protocol. The group will extend the >>> IKEv2 protocol to support key agreement using these curves and their >>> related functions. >>>=20 >>> This charter will expire in August 2016. If the charter is not = updated before >>> that time, the WG will be closed and any remaining documents revert = back to >>> individual Internet-Drafts. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 4 10:03:51 2016 Return-Path: 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 BED931A7012 for ; Fri, 4 Mar 2016 10:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 L8mq85s6vqjn for ; Fri, 4 Mar 2016 10:03:48 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3D61A700E for ; Fri, 4 Mar 2016 10:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457114627; x=2321028227; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k8pH/CpGO/sjaPTGho33u9FXNU4zUJMu5kgj6P/5ebA=; b=lxWRlvmj4OV77phw+3s+g5rklR9plYR7x+Q4ncGqgLhe24w17xL29+Fe8PObLyL5 hwRo+XigLeTy0ewuOlyAjRzzF6xhvixmMt0stvHmoWyQlLx8ywFHfOsa4SNMPZEM GniO6jlYtL/V//mAFsAcaXIRI+WKuFvT6u/jxo2Pj27N28TN0h6JN6xK7Dyn4uQ+ 5ASx4ZWPvvuPgVlDX5lmBSPTml6b9XcKBPtkn/owkJKODADiKp/+KxrDwl3Bsgv7 IpSulboL5ihbsZviTtoZ86+vArTpRjlifRXq/ymln4D8RWRvEDhZgNqxIPolF/ND bVPo9sp0wraymR3NWQTXNQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 32.91.25552.30EC9D65; Fri, 4 Mar 2016 10:03:47 -0800 (PST) X-AuditID: 11973e16-f79bc6d0000063d0-b2-56d9ce0383a5 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id F3.89.18091.30EC9D65; Fri, 4 Mar 2016 10:03:47 -0800 (PST) Received: from [17.226.23.78] (unknown [17.226.23.78]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3J00GQO0UAGV20@chive.apple.com> for ipsec@ietf.org; Fri, 04 Mar 2016 10:03:47 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_81DA9EB0-8845-4079-9B7F-66F268556CE6" MIME-version: 1.0 (Mac OS X Mail 10.0 \(3169\)) From: Tommy Pauly In-reply-to: Date: Fri, 04 Mar 2016 10:03:47 -0800 Message-id: References: To: Yoav Nir X-Mailer: Apple Mail (2.3169) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FAYpct87maYwZkPchb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsFZf9gLLgVW7Lqwjq2BcY1rFyMnh4SAicSt5YvYIGwxiQv3 1oPZQgJ7GSWu7JSFqZm28itTFyMXUHwak8S7lwsYIZwuJolfd9qAMhwcwgISEpv3JII0MAsk SXT9W8sEYvMK6Et0tk1kBLGFBZwkbqx8DhZnE1CROP5tAzOIzSlgK3HmwRx2EJtFQFWie8Z8 sPnMAs2MEtMWvmOGGGQjsffnGqgrDjFJbN04mQUkISKgJHH4yldmiFNlJV5d38MGUiQhMIVN 4sC6N8wTGIVnIblqFpKrIOLaEssWvmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypGodzEzBzdzDxz vcSCgpxUveT83E2MoJiYbie2g/HhKqtDjAIcjEo8vDcarocJsSaWFVfmHmKU5mBREufdLAQU EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMg0pemQdXRSksm+7/b8RlO0vm+4dXTZKbPrt9PC 1V78u/nr3ZLqff4PH33m2rNcvInHMFKwQnG1Sk6sec7rT6LCGi7vXoWqGidPm9iTcz1H0G8y i/O1GYbT5ves/DKdeUpd/O0rbouqLaLnJ3n1HZuzfAaPTGPV5+rOsJcHErRP8Czq5je47KzE UpyRaKjFXFScCABezqfiagIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUi2FDMr8t87maYQf9dPov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+CsP+wFlwIrdl1Yx9bAuMa1i5GTQ0LARGLayq9MELaYxIV7 69m6GLk4hASmMUm8e7mAEcLpYpL4dacNqIqDQ1hAQmLznkSQBmaBJImuf2vBmnkF9CU62yYy gtjCAk4SN1Y+B4uzCahIHP+2gRnE5hSwlTjzYA47iM0ioCrRPWM+2HxmgWZGiWkL3zFDDLKR 2PtzDRPE4kNMEls3TmYBSYgIKEkcvvKVGeJUWYlX1/ewTWAUmIXkkFlIDoGIa0ssW/iaGcLW lNjfvZwFU1xDovPbRNYFjGyrGAWKUnMSK830EgsKclL1kvNzNzGCg7gwagdjw3KrQ4wCHIxK PLw3Gq6HCbEmlhVX5h5ilOBgVhLhXbv7ZpgQb0piZVVqUX58UWlOavEhRmkOFiVxXrMTV8OE BNITS1KzU1MLUotgskwcnFINjHwmOVmB8VIfP4RwN1ncSqiKulXRfVrow85X3YyHJsiG+U9J 7PHseMMxxc/osPjsnYcnvLJM0F/Wzlf2RnA1h2zYglUTgx/OeVwS/kjl315llaeGtx7+j7OX yLScfj1Q85zRnom1c9tiVtQXr7hrvi7FYcndI0anDmtMtPnitts7/Pu5141y5UosxRmJhlrM RcWJANH2imBeAgAA Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 18:03:49 -0000 --Apple-Mail=_81DA9EB0-8845-4079-9B7F-66F268556CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 4, 2016, at 9:32 AM, Yoav Nir wrote: >=20 >>=20 >> On 4 Mar 2016, at 7:02 PM, Tommy Pauly wrote: >>=20 >> Hello Dave, >>=20 >> I tend to agree with Paul that I find it unlikely, from an = implementor=E2=80=99s standpoint, that many Initiators will choose to = implement the puzzle logic, especially ones that are running on mobile = devices. It is unlikely that the phones will be able to solve the = puzzles quickly enough to beat out botnets, and it would be hard to = justify the battery consumption necessary. That being said, the document = does a very good job of explaining the problem space, and the other = parts of its solution (rate-limiting and suggesting session resumption) = make good sense. Perhaps there can be more focus on how a responder can = best protect itself if indeed the majority of its clients do not support = puzzles? >>=20 >> One question on section 7.1.2: >>=20 >> If the received message contains a PUZZLE notification and doesn't >> contain a COOKIE notification, then this message is malformed = because >> it requests to solve the puzzle, but doesn't provide enough >> information to do it. In this case the Initiator SHOULD resend >> IKE_SA_INIT request. If this situation repeats several times, then >> it means that something is wrong and the IKE SA cannot be >> established. >>=20 >> I am concerned that the suggestion for the initiator reacting to = malformed IKE_SA_INIT packets is to send more traffic to the responder. = The responder should not legitimately send a PUZZLE notification without = a COOKIE notification, since this would be invalid. If the initiator = sees this, it can either assume that (a) the responder=E2=80=99s = implementation is out of spec, or (b) some malicious third party is = deliberately modifying the unencrypted packet. In the first case, trying = to send the IKE_SA_INIT again would be in vain; in the second case, we = have provided a way for a third party to cause initiators to send more = traffic to the responder, thus providing an attack vector. What are your = thoughts on this? >=20 > A proper responder would not send a malformed packet. An attacker = could send a malformed response immediately after the initiator sends = the request. By the time the initiator gets the real responder=E2=80=99s = response, it has lost state.=20 >=20 > That is why it is always a good idea (not just in this context) for = the initiator to ignore malformed responses until the timeout is = reached. That makes sense. The wording, however, could imply that the Initiator = should resend the request as if in response to the malformed packet. = Based on your comment, the Initiator should wait for the usual amount of = time before retrying, rather than immediately retrying the packet. It = may be useful to clarify this in the text. Thanks, Tommy >=20 > Yoav --Apple-Mail=_81DA9EB0-8845-4079-9B7F-66F268556CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 4, 2016, at 9:32 AM, = Yoav Nir <ynir.ietf@gmail.com> wrote:


On 4 Mar 2016, at 7:02 PM, Tommy = Pauly <tpauly@apple.com> wrote:

Hello Dave,

I tend to agree with = Paul that I find it unlikely, from an implementor=E2=80=99s standpoint, = that many Initiators will choose to implement the puzzle logic, = especially ones that are running on mobile devices. It is unlikely that = the phones will be able to solve the puzzles quickly enough to beat out = botnets, and it would be hard to justify the battery consumption = necessary. That being said, the document does a very good job of = explaining the problem space, and the other parts of its solution = (rate-limiting and suggesting session resumption) make good sense. = Perhaps there can be more focus on how a responder can best protect = itself if indeed the majority of its clients do not support puzzles?

One question on section 7.1.2:
If the received message contains a PUZZLE notification and = doesn't
 contain a COOKIE notification, then this = message is malformed because
 it requests to solve = the puzzle, but doesn't provide enough
 information = to do it.  In this case the Initiator SHOULD resend
 IKE_SA_INIT request.  If this situation repeats = several times, then
 it means that something is wrong = and the IKE SA cannot be
 established.

I am concerned that the suggestion for the = initiator reacting to malformed IKE_SA_INIT packets is to send more = traffic to the responder. The responder should not legitimately send a = PUZZLE notification without a COOKIE notification, since this would be = invalid. If the initiator sees this, it can either assume that (a) the = responder=E2=80=99s implementation is out of spec, or (b) some malicious = third party is deliberately modifying the unencrypted packet. In the = first case, trying to send the IKE_SA_INIT again would be in vain; in = the second case, we have provided a way for a third party to cause = initiators to send more traffic to the responder, thus providing an = attack vector. What are your thoughts on this?

A proper responder would not send a malformed = packet. An attacker could send a malformed response immediately after = the initiator sends the request. By the time the initiator gets the real = responder=E2=80=99s response, it has lost state. 

That is why it is always a good idea (not = just in this context) for the initiator to ignore malformed responses = until the timeout is reached.

That makes = sense. The wording, however, could imply that the Initiator should = resend the request as if in response to the malformed packet. Based on = your comment, the Initiator should wait for the usual amount of time = before retrying, rather than immediately retrying the packet. It may be = useful to clarify this in the text.

Thanks,
Tommy


Yoav

= --Apple-Mail=_81DA9EB0-8845-4079-9B7F-66F268556CE6-- From nobody Fri Mar 4 12:47:15 2016 Return-Path: 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 C76E41A8A45 for ; Fri, 4 Mar 2016 12:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 0L6M3rn3yRns for ; Fri, 4 Mar 2016 12:47:11 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 881D51A8A41 for ; Fri, 4 Mar 2016 12:47:11 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qH1Mc1SnRzCWQ; Fri, 4 Mar 2016 21:47:08 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HbNoSXW190BK; Fri, 4 Mar 2016 21:47:07 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 4 Mar 2016 21:47:07 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9D23B603BBA1; Fri, 4 Mar 2016 15:47:06 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9D23B603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9BB1CA3C7; Fri, 4 Mar 2016 15:47:06 -0500 (EST) Date: Fri, 4 Mar 2016 15:47:06 -0500 (EST) From: Paul Wouters To: Tommy Pauly In-Reply-To: <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> Message-ID: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 20:47:12 -0000 On Fri, 4 Mar 2016, Tommy Pauly wrote: > I would also like to see the draft for TCP encapsulation added as an item, since we’ve gotten a fair amount of support for it. For the purposes of the charter, it may be good to have a broader explanation of the goal—something to the effect that the working group should focus on making sure that IKEv2 can be deployed more universally by taking into account limitations of various networks. Previous RFCs like IKE fragmentation have contributed to this; TCP encapsulation tries to solve another set of problematic networks; and we can imagine that there may be more to investigate, such as taking into account the limitations and requirements of IoT networks, etc. Yes please. Note there is also the DNS(SEC) work in our other draft as well. Paul From nobody Sat Mar 5 02:01:08 2016 Return-Path: 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 3D29F1B2C02 for ; Sat, 5 Mar 2016 02:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpdCibM9WFIa for ; Sat, 5 Mar 2016 02:01:05 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C5C1B2BFC for ; Sat, 5 Mar 2016 02:01:04 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id x1so85757660lbj.3 for ; Sat, 05 Mar 2016 02:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=vkHuNF8CXI9ASKS7tLrPQiHSGnKBxr0DspWfb7+i2bs=; b=kgRO0zCASW+NeMb4GwnjTKbGdmpgusOIKj4Xrmor/Qb3dDoE9BUKjHUm8PCJ4lA39n Qr+RJr+2+Vi7hxejh1HnhTl8afHOopjLYJRgujxK5OJN1B25SJeklUx+o8kEL3onvmps oWX1yeAJTm7gBvq+lnTor94dDbsBJz+g/rpkKHfm3s81fod1CqZ9xax6ZNWutJUavNX3 lZ9EJER6L3u8ADREEkMzB9bLcchjVntKv54TLbcitImcZ2h1Hnb/roSYKDnY2RDFJa1F Z/Bu35FITdOySp36B97UUr7Czrt9UtKUN6PPRqDklANQLJfIxjlx/+69iK8urYygSqS0 USVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=vkHuNF8CXI9ASKS7tLrPQiHSGnKBxr0DspWfb7+i2bs=; b=H0B+QbY6itOLeV24icp0POi/adT4eK8ZdVgX2uQ4L5XDt7kfQgmFgqeHn5Yx8ozoxq H84s1V/GHEmODcMXw2hu0wNLQuol6CGDona6Sl9BC9DaGaBFRUxAF5Q/F3YWrFnUPrcL ogumzbK8SogIKmRHr0QVnQYQxhrfidZOoUI98mK2lI1TmrOkIfxZ3QkqqAYd+ZR0f2x6 tXXOc1Z3xU1LaGxj2K/UxFI5qE9rkVSErNPDjxY7LpX9AvPA2/D3HsGAmL8mxIxAuhXN rNArXb6Iyv7c97CCsfFWvyg1RYU04ZXTf7L+upF98KNYf39m4I82e0AlI/OQYGYJYOjG JkCw== X-Gm-Message-State: AD7BkJIUA1Nb/J/w+GRLqHXk/mLUBNfj5edHaDw7H1DcJK0a9Iyym3dhQiXvlcVgXiD5IQ== X-Received: by 10.112.146.35 with SMTP id sz3mr4639838lbb.10.1457172062550; Sat, 05 Mar 2016 02:01:02 -0800 (PST) Received: from chichi (ppp83-237-43-99.pppoe.mtu-net.ru. [83.237.43.99]) by smtp.gmail.com with ESMTPSA id e6sm1209477lbc.15.2016.03.05.02.01.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2016 02:01:01 -0800 (PST) Message-ID: <7CC6BEAF37124C56930D7769EF7B9848@chichi> From: "Valery Smyslov" To: "Tommy Pauly" , "Yoav Nir" References: In-Reply-To: Date: Sat, 5 Mar 2016 13:00:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 10:01:06 -0000 Hi Tommy, thank you for your comments. >>> I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will >>> choose >>> to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones >>> will be able >>> to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption >>> necessary. >>> That being said, the document does a very good job of explaining the problem space, and the other parts of its >>> solution >>> (rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a >>> responder >>> can best protect itself if indeed the majority of its clients do not support puzzles? Sections 4 - 6 describe measures other than puzzles that the responder can use to defend itself against DDoS attack. Do you think it is not enough? Puzzles are a new thing, that's why more text is needed to explain how they are fit into the protocol. However the draft is not solely about puzzles, and I think it covers other defending techniques in sufficient details. >>> One question on section 7.1.2: >>> >>> If the received message contains a PUZZLE notification and doesn't >>> contain a COOKIE notification, then this message is malformed because >>> it requests to solve the puzzle, but doesn't provide enough >>> information to do it. In this case the Initiator SHOULD resend >>> IKE_SA_INIT request. If this situation repeats several times, then >>> it means that something is wrong and the IKE SA cannot be >>> established. >>> >>> I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more >>> traffic to the responder. >>> The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be >>> invalid. >>> If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some >>> malicious third party >>> is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be >>> in vain; >>> in the second case, we have provided a way for a third party to cause initiators to send more traffic to the >>> responder, >>> thus providing an attack vector. What are your thoughts on this? >>> >> A proper responder would not send a malformed packet. An attacker could send a malformed response immediately >> after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost >> state. >> >> That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until >> the timeout is reached. >> > That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to > the malformed packet. > Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately > retrying the packet. > It may be useful to clarify this in the text. You are right that the Initiator should wait for the retransission timer to expire before resending message. I agree that the wording is ambiguous about that. How about the following? If the received message contains a PUZZLE notification and doesn't contain a COOKIE notification, then this message is malformed because it requests to solve the puzzle, but doesn't provide enough information to do it. In this case the Initiator MUST ignore the received message and continue to wait until either the valid one is received or the retransmission timer fires. If it fails to receive the valid message after several retransmissions of IKE_SA_INIT request, then it means that something is wrong and the IKE SA cannot be established. Regards, Valery. > Thanks, > Tommy From nobody Sat Mar 5 02:35:02 2016 Return-Path: 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 902D41B2D4C for ; Sat, 5 Mar 2016 02:35:01 -0800 (PST) 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 VWRBxxAlX8KD for ; Sat, 5 Mar 2016 02:34:59 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8264B1B2CE6 for ; Sat, 5 Mar 2016 02:34:59 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id cf7so69976681lbb.1 for ; Sat, 05 Mar 2016 02:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=w73iWwrSS0Hn7dhdPUG/VcmSB3XeBKOOr4SDrnjzJCg=; b=CpJ3jfaPiCww9Gg4gwWzoh7L86F/liBy67ccTVDj6g6Ig5/2zvJ47o2bQZ/kauXHka Vs2yn27qh86Us/MP+srq3v6axsZREBWi01Un71f5ljdzbNbgGsH+P/cSkG3mUYZ1Z8Bz r0Yvj0U738i85/uGAi0FoJ1aTa6/tfZEQFnf2Ilrh0JkJozBeW4neZ2KADn3nhl87gYk e0HZBO8ZVtu5EyRTbS4ipndTN8G/QC6b4plK2rqFKVkVnhpwDfY1srS90QxB9HWg5y0/ AsjYNmfwuwqTY43rIQyDizmsVuEHgKMm6g8T+n6OD3V9eYrAIE+e/Zg3rluyyRbMLlxH +lPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=w73iWwrSS0Hn7dhdPUG/VcmSB3XeBKOOr4SDrnjzJCg=; b=KB9cQj4JSbUUw4e2tHv+qJrJY4U2pGEk1ZFY/uZsih8twgPB8htAAyQqyXSZplmiXn C69W1CnBFxAeTTDHM+K0XnPhEL8/3TN9AJfneKYGN/+esecWaqnGR9s5weQfHMeKdIpc bsnIeqb+KhjwNqy3Piyw7MsUeg3lFMUDlJ0km6/kuZ7kxWiVFHsVMyL4q/szBLySS3SB 4F3hHXMyei8itVT8j58syC9NAUN00PXDAl6gnUNx2w77O12d9we9xKFBltNeKjlx9f5g 6Ke1+u4eOMeHUx8Ek0imX11MmaX7uSy7hEYdH8G1WYR1AC550ipLYzQtuCe7wYTHaP+f mrvA== X-Gm-Message-State: AD7BkJIEL1JO4KAqEHBuJNm0XYlUNFXC2VnsIffQcb4kY07IHN68ZRvsdN5eWdheMTY+Wg== X-Received: by 10.25.42.13 with SMTP id q13mr4681607lfq.96.1457174097738; Sat, 05 Mar 2016 02:34:57 -0800 (PST) Received: from chichi (ppp83-237-43-99.pppoe.mtu-net.ru. [83.237.43.99]) by smtp.gmail.com with ESMTPSA id zs6sm1211662lbb.38.2016.03.05.02.34.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2016 02:34:56 -0800 (PST) Message-ID: <1913628F357D497DABAB6D43640A02A7@chichi> From: "Valery Smyslov" To: "Paul Wouters" , "Waltermire, David A. \(Fed\)" References: In-Reply-To: Date: Sat, 5 Mar 2016 13:34:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 10:35:01 -0000 Hi Paul, thank you for your comments. > I think the document is well written with respect to DDOS. I like > everything except the puzzles. It seems a lot of complexity for > no gain, especially with the problem being that botnets are better > at puzzle solving then mobile phones who want to not drain their > batteries. I would prefer this document to proceed without the > puzzles, but I won't object to it if it remains in the document. > As an implementor, it would be extremely unlikely that I would > implement puzzles. I agree that puzzles is a controversal thing. However currently we have no better idea how at least to try to defend against powerful botnets. If you can come up with such an idea, you are very welcome. (W.Churchill said that democracy is the worst form of government, except all those others that have been tried. [1] I think that's a good analogy for puzzles.) And note, that the way puzzles are used in the draft makes every attempt to not discriminate those initiators that don't support puzzles or cannot afford enough power to solve them. In other words - puzzles mechanism in the draft is not an absolute barrier for unsupported clients, it is just a first-class ticket for those who support and afford. > Recently, I also thought about amplification attacks, which is not > covered by the document. For instance, legitimate clients could pad > their IKE_INIT Request as a way to tell the responder they are not just > using the responder to amplify a DDOS attack. I am thinking of making > that the default for some Opportunistic IPsec so it cannot be abused for > amplification. I'd like to see that added to the draft if possible. Or > if this document would not proceed, I would be tempted to write a draft > for this idea. Could you, please, elaborate what scenario do you have in mind? > Paul Regards, Valery. [1] http://www.academia.edu/1877336/_It_has_been_said_that_democracy_is_the_worst_form_of_government_except_all_those_others_that_have_been_tried_Winston_Churchill From nobody Sat Mar 5 03:32:58 2016 Return-Path: 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 15A941B2ECA for ; Sat, 5 Mar 2016 03:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 bmoV2czeWHwM for ; Sat, 5 Mar 2016 03:32:56 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 B94161B2EC6 for ; Sat, 5 Mar 2016 03:32:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qHP1c3J8Vz4Kc; Sat, 5 Mar 2016 12:32:52 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id AdCPX3qsScri; Sat, 5 Mar 2016 12:32:51 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 5 Mar 2016 12:32:51 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9EC0C6066252; Sat, 5 Mar 2016 06:32:49 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9EC0C6066252 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 99A91A3C7; Sat, 5 Mar 2016 06:32:49 -0500 (EST) Date: Sat, 5 Mar 2016 06:32:49 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <1913628F357D497DABAB6D43640A02A7@chichi> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 11:32:57 -0000 On Sat, 5 Mar 2016, Valery Smyslov wrote: > I agree that puzzles is a controversal thing. However currently we have no > better idea how at least to try to defend against powerful botnets. If you > can come up with such an idea, you are very welcome. If there is no consensus about puzzles, perhaps we should leave that part out of the document? > And note, that the way puzzles are used in the draft makes every > attempt to not discriminate those initiators that don't support puzzles > or cannot afford enough power to solve them. In other words - > puzzles mechanism in the draft is not an absolute barrier for > unsupported clients, it is just a first-class ticket for those who support > and afford. which is the botnet more than mobile phones. Which is why I don't see I would implement this. It seems session resumption would be more effective at distinguishing returning clients from a botnet. >> Recently, I also thought about amplification attacks, which is not >> covered by the document. For instance, legitimate clients could pad >> their IKE_INIT Request as a way to tell the responder they are not just >> using the responder to amplify a DDOS attack. I am thinking of making >> that the default for some Opportunistic IPsec so it cannot be abused for >> amplification. I'd like to see that added to the draft if possible. Or >> if this document would not proceed, I would be tempted to write a draft >> for this idea. > > Could you, please, elaborate what scenario do you have in mind? If you have an IPsec server willing to talk IKE/IPsec to anonymous clients. So one-side AUTH_NULL, the other a real authentication. Since the server talks to everyone who sends it an IKE_INIT, it is important that this IKE_INIT reply is much smaller than the IKE_INIT request, so this does not become a new amplification target. Currently, such a server could only always require dcookies to accomplish this, but that takes an additional round trip. Some kind of padding in the IKE_INIT request could easilly prevent this. Paul From nobody Sat Mar 5 05:11:35 2016 Return-Path: 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 958891B312A for ; Sat, 5 Mar 2016 05:11:33 -0800 (PST) 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 uePYZj4p-WHQ for ; Sat, 5 Mar 2016 05:11:32 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFE61B3128 for ; Sat, 5 Mar 2016 05:11:31 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id k15so88566350lbg.0 for ; Sat, 05 Mar 2016 05:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=YDyo10X5M5WSxqhaVhXeBi3TqY/rsVXTiRKvopyuvhA=; b=ggMPXZ9xalkGhpG/h26Tgpm2neGnN24o8yMPkDOajkKkJbV5VYoqEiEhftHwMQrq1a R9ep48g7R8jiacHVsjoGwDrC7ndySwCDAgGdL1w+pX56qw38eFmKfAWutzcxqff0kFU+ mUvLdR6ZlKk7L3UzJ0LliSBC6zrEfPQj5Fejh2ds2T7ZxBeJjd5lMblEhnv1BIiPMLy9 5KrNY2vDDCBoQSYJ6LqsGZK/3b2QuwVcz7VUtMjnbHfDLT0pkBMSB1kDCvfz8wbdEAeN DSWLYVPRxrE1e4Vyd9JwpTcpTR5Ih/VM5oCZ1aATdMPsgW1W2PUOhNJJrdEDHjKzs6ye CkVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=YDyo10X5M5WSxqhaVhXeBi3TqY/rsVXTiRKvopyuvhA=; b=LHM23MTCxzSKHmadHtC9+pBK297mJs3QqCI+XuUWZ0axhkQNAm8E6XJqPtymquBJ8/ RvU9346ZNkA56/oOibLJVMitc/z74wPZc8WgBAh3sjD1Rx0wwEDpnpwWt/TAE9Y9g1o4 TUKryJ7a6RbXRPPJ5xfTAp1Pod5Xe0jZA2IDQH5K3sjBqZlUgEzFEmjz/aRA2Yxs7tcs +roA9QPPrfU/KTEpsw9LtkNg7r/bZALdLqG7p6mxso+7FYdb0yqisf84K4RB2jup0f/U HHJvHrV8bcihTzpgYqOsJMDu/cDBj+N28kKHVdM6fEpWSevaM0aSWzw0hyeInDCyKGsC nt1A== X-Gm-Message-State: AD7BkJLPvmm0GfKnPqQ5n113j8dbzuf1yxO+bNEkX4ugodhvsO+Ue4ikm3O9p9mfu6i4vQ== X-Received: by 10.25.170.85 with SMTP id t82mr3736914lfe.57.1457183490006; Sat, 05 Mar 2016 05:11:30 -0800 (PST) Received: from chichi (ppp83-237-43-99.pppoe.mtu-net.ru. [83.237.43.99]) by smtp.gmail.com with ESMTPSA id zr6sm679446lbb.19.2016.03.05.05.11.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Mar 2016 05:11:29 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <1913628F357D497DABAB6D43640A02A7@chichi> In-Reply-To: Date: Sat, 5 Mar 2016 16:11:21 +0300 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 13:11:33 -0000 > If there is no consensus about puzzles, perhaps we should leave that > part out of the document? I had an impression that threre was a consensus when the document was adopted by WG. In any case, I think that it is better to have an interoperable specification than to leave puzzles at all (and thus make them a subject for a proprietary solutions). >> And note, that the way puzzles are used in the draft makes every >> attempt to not discriminate those initiators that don't support puzzles >> or cannot afford enough power to solve them. In other words - >> puzzles mechanism in the draft is not an absolute barrier for >> unsupported clients, it is just a first-class ticket for those who support >> and afford. > > which is the botnet more than mobile phones. Which is why I don't see I > would implement this. It seems session resumption would be more > effective at distinguishing returning clients from a botnet. Sure. But before every client becomes a "returning" one it must pass usual IKE_SA_INIT. And it cannot be a returning client the rest of its life - it must be fully reauthenticated from time to time. Thus the resumption cannot make the task of DDoS protection in IKE_SA_INIT non-existent. >> Could you, please, elaborate what scenario do you have in mind? > > If you have an IPsec server willing to talk IKE/IPsec to anonymous > clients. So one-side AUTH_NULL, the other a real authentication. Since > the server talks to everyone who sends it an IKE_INIT, How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder doesn't yet know that the initiator will use NULL auth or real auth, so any server usually replies to everyone who sends IKE_SA_INIT request. > it is important > that this IKE_INIT reply is much smaller than the IKE_INIT request, > so this does not become a new amplification target. IKE_SA_INIT reply in most cases is smaller than request. The responder returns only a subset of initiator's SA transforms, a subset of initiator's notifications (returning only supported ones), and usually only a subset of VIDs. In which real life scenario it is larger than request? > Currently, such > a server could only always require dcookies to accomplish this, but > that takes an additional round trip. Some kind of padding in the > IKE_INIT request could easilly prevent this. Sorry, I failed to understand how additional padding would work. Are you going to reject initiators that don't include this additional padding (i.e. - all usual IKEv2 clients)? Am I missing something? Regards, Valery. > Paul From nobody Sat Mar 5 17:38:28 2016 Return-Path: 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 CA41D1A8759 for ; Sat, 5 Mar 2016 17:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 5AULXETFj17y for ; Sat, 5 Mar 2016 17:38:26 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D96C1A8757 for ; Sat, 5 Mar 2016 17:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457228305; x=2321141905; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xF/PSRt1J7TTTXXQVqqZL/5J4zeFAXmXbeCS7nABYe8=; b=OrlA2rjdC177heLjiNoKMUEPj3rfSH2oHvcvSHmeouh77HcvsxjvQq7uvrunwtOr U/yYZIRjCdaMAvi6uMNBfX5FebBEiVE6h1OvWlyOO1duN5D40W3Iu3CxgbhRdCWX /WUek2uvbxM2aFeDQvxB0qR+7xqtFx6goQYgn9JE9pAONxCVVomzJMIWvkSKWQm+ BLUGa6ZwgiGr6/HSaI1z5+ElApMH31OkMfMQD3ccik7oXFllhcRdUNFK/FE/USVE TbhWeo/GotSyWiV2vxz7pAjcmoDE5V2UdnwukE6rigtNw7eyfjodHbzTpxSDP5el 7uSWnMEMsZJx8h7GCKHqbg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id AF.17.03030.11A8BD65; Sat, 5 Mar 2016 17:38:25 -0800 (PST) X-AuditID: 11973e13-f798e6d000000bd6-40-56db8a11bd82 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 8D.4B.25582.11A8BD65; Sat, 5 Mar 2016 17:38:25 -0800 (PST) Received: from [17.153.35.61] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3L00J1VGK0PH10@nwk-mmpp-sz09.apple.com> for ipsec@ietf.org; Sat, 05 Mar 2016 17:38:25 -0800 (PST) Sender: tpauly@apple.com MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) Content-type: text/plain; charset=utf-8 From: Tommy Pauly X-Priority: 3 In-reply-to: <7CC6BEAF37124C56930D7769EF7B9848@chichi> Date: Sat, 05 Mar 2016 17:38:24 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <7CC6BEAF37124C56930D7769EF7B9848@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FAYoSvYdTvMYNFSdYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+PU+4wFG9QrXv3/ytbA+Fi+i5GTQ0LAROL81UPMELaYxIV7 69m6GLk4hAT2Mkq8ntHFClM05W8DVGIZk8S7HY0sEE4jk8SCnq9AVRwcwgISEpv3JII0CAs4 SdxY+ZwJJMwroC/x60w4iMksoC4xZUouSAWbgIrE8W8boPbySsxof8oCYnMKmEncXf8AbC2L gKrE6u33wGxmgX5GiY8nTSBsbYkn7y6AxXkFbCR6N65jhLhmIbPEzPsrmEASIkDNN7f9hFog K3Hn+GmwkyUENrBJPPpwgHkCo+gshPNmIZw3C8mKBYzMqxiFchMzc3Qz80z1EgsKclL1kvNz NzGCQn66nfAOxtOrrA4xCnAwKvHwRlbeDhNiTSwrrsw9xCjNwaIkzuv84WaYkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsZV7L88mSZs2x5+6n7nk6AHiTY+ltxr/uQ4XjWcaPqNVX7q6i+2 y26rrupaHzz956H8/T3lMcElruuMt4ZMdDJt7DxySkpczpctX6XEqbpjQoZ7yOkVjayFqlHZ by7pRySf3sJcyFm3eeGCQt1Yz03Ppjrxh3Re3568LDTRT0ZBPyzOZndonBJLcUaioRZzUXEi APtMlM9aAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRbCgO0BXsuh1m8OWQgsX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XHqfcaCDeoVr/5/ZWtgfCzfxcjJISFgIjHlbwMbhC0mceHe eiCbi0NIYBmTxLsdjSwQTiOTxIKer6xdjBwcwgISEpv3JII0CAs4SdxY+ZwJJMwroC/x60w4 iMksoC4xZUouSAWbgIrE8W8bmCHG80rMaH/KAmJzCphJ3F3/gBXEZhFQlVi9/R6YzSzQzyjx 8aQJhK0t8eTdBbA4r4CNRO/GdYwQ1yxklph5fwUTSEIEqPnmtp9QC2Ql7hw/zTKBUWgWwkWz EC6ahWTqAkbmVYwCRak5iZWmeokFBTmpesn5uZsYwSFaGLGD8f8yq0OMAhyMSjy8L57dDBNi TSwrrsw9xCjBwawkwluQfDtMiDclsbIqtSg/vqg0J7X4EGMy0C8TmaVEk/OB8ZNXEm9oYmJg YmxsZmxsbmJOmrCSOK/JiathQgLpiSWp2ampBalFMFuYODilGhgPiRk9/ltwbyqn8ynmGZmN x45MtCyWEvr6a0/Wzrw4r2knlh+1WOXHbsvpWFqfJezt1bVQaP2/Cfv7flxb+sd+TpHDrtx0 34sfHrZliInmbTQwYs5y+O2heexh5IEFFdGaYd1hBwKW6XKbG17b/SptW/Fke1s9x6naM469 eV9UFV3/5UDd11YlluKMREMt5qLiRAAr5LedlQIAAA== Archived-At: Cc: ipsec@ietf.org, Paul Wouters , "Waltermire, David A. \(Fed\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 01:38:28 -0000 Hi Valery, Responses inline. Thanks! Tommy > On Mar 5, 2016, at 2:00 AM, Valery Smyslov wrote: >=20 > Hi Tommy, >=20 > thank you for your comments. >=20 >>>> I tend to agree with Paul that I find it unlikely, from an = implementor=E2=80=99s standpoint, that many Initiators will choose >>>> to implement the puzzle logic, especially ones that are running on = mobile devices. It is unlikely that the phones will be able >>>> to solve the puzzles quickly enough to beat out botnets, and it = would be hard to justify the battery consumption necessary. >>>> That being said, the document does a very good job of explaining = the problem space, and the other parts of its solution >>>> (rate-limiting and suggesting session resumption) make good sense. = Perhaps there can be more focus on how a responder >>>> can best protect itself if indeed the majority of its clients do = not support puzzles? >=20 > Sections 4 - 6 describe measures other than puzzles that the responder = can use to defend itself against DDoS attack. > Do you think it is not enough? Puzzles are a new thing, that's why = more text is needed to explain how they are fit > into the protocol. However the draft is not solely about puzzles, and = I think it covers other defending techniques in sufficient details. Perhaps it would be useful to rearrange the sections to highlight this = more clearly. The first section about a solution is Puzzles (section 3), = followed by sections 4-6 which cover other aspects of DDoS avoidance = strategies, which is then followed by an in-depth explanation of the = Puzzles in the protocol (sections 7-9). Since the other aspects and = sandwiched in between sections purely focused on puzzles, the draft = really feels like it is about puzzles. What if the other approaches were = moved before the first puzzles section, so the entire section on puzzles = can be contiguous? >=20 >>>> One question on section 7.1.2: >>>>=20 >>>> If the received message contains a PUZZLE notification and doesn't >>>> contain a COOKIE notification, then this message is malformed = because >>>> it requests to solve the puzzle, but doesn't provide enough >>>> information to do it. In this case the Initiator SHOULD resend >>>> IKE_SA_INIT request. If this situation repeats several times, then >>>> it means that something is wrong and the IKE SA cannot be >>>> established. >>>>=20 >>>> I am concerned that the suggestion for the initiator reacting to = malformed IKE_SA_INIT packets is to send more traffic to the responder. >>>> The responder should not legitimately send a PUZZLE notification = without a COOKIE notification, since this would be invalid. >>>> If the initiator sees this, it can either assume that (a) the = responder=E2=80=99s implementation is out of spec, or (b) some malicious = third party >>>> is deliberately modifying the unencrypted packet. In the first = case, trying to send the IKE_SA_INIT again would be in vain; >>>> in the second case, we have provided a way for a third party to = cause initiators to send more traffic to the responder, >>>> thus providing an attack vector. What are your thoughts on this? >>>>=20 >>> A proper responder would not send a malformed packet. An attacker = could send a malformed response immediately >>> after the initiator sends the request. By the time the initiator = gets the real responder=E2=80=99s response, it has lost state. >>>=20 >>> That is why it is always a good idea (not just in this context) for = the initiator to ignore malformed responses until the timeout is = reached. >>>=20 >> That makes sense. The wording, however, could imply that the = Initiator should resend the request as if in response to the malformed = packet. >> Based on your comment, the Initiator should wait for the usual amount = of time before retrying, rather than immediately retrying the packet. >> It may be useful to clarify this in the text. >=20 > You are right that the Initiator should wait for the retransission = timer to expire before resending message. > I agree that the wording is ambiguous about that. How about the = following? >=20 > If the received message contains a PUZZLE notification and doesn't > contain a COOKIE notification, then this message is malformed because > it requests to solve the puzzle, but doesn't provide enough > information to do it. In this case the Initiator MUST ignore > the received message and continue to wait until either the valid one > is received or the retransmission timer fires. If it fails to receive = the valid > message after several retransmissions of IKE_SA_INIT request, then > it means that something is wrong and the IKE SA cannot be = established. I think that is more clear, thanks! >=20 > Regards, > Valery. >=20 >> Thanks, >> Tommy >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Mar 5 17:49:39 2016 Return-Path: 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 38CE41A87C3 for ; Sat, 5 Mar 2016 17:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 oy4kJyki0nwF for ; Sat, 5 Mar 2016 17:49:36 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970721A87C8 for ; Sat, 5 Mar 2016 17:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1457228976; x=2321142576; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Npg3+Fwq8rCowXNipc5T7xj/wW4IlcWpJfWGyM/KhgU=; b=hFSiG/CyB5uvggSH9pL5wFHqYv4Vb9BTr9m+vRTh4Lrzh1EKG+YIEMFgMMDx5hws uyPWCEPOz1C1Fj3hiTVgAGefDjKOSQnM5xnw4a+UhxD9cvHl3bOjT4Ft2eo9eIk1 A379dgmIX9ggUcksk7CQ69l7+6cTaKpUmGVdsDV5lMhd66IepyaxCCgt+iTS8S45 4UuVe+1CuCykW01svMki4Yw05tQwm3wgIAaffgFHDLsicDZc5JI6h0C/9oH9D6w4 xjuUzBYjz9yqC6qGhwdzNOLwtsJpxLVnwAZkBDVU6mUnsCetVicpYFut2q6nP4p7 nxNVmCxsOMr2UfGMEGzZxA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A7.1C.27179.0BC8BD65; Sat, 5 Mar 2016 17:49:36 -0800 (PST) X-AuditID: 11973e15-f79686d000006a2b-c3-56db8cb0af68 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id AB.22.25582.0BC8BD65; Sat, 5 Mar 2016 17:49:36 -0800 (PST) Received: from [17.153.35.61] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O3L00J5WH2NPH10@nwk-mmpp-sz09.apple.com> for ipsec@ietf.org; Sat, 05 Mar 2016 17:49:36 -0800 (PST) Sender: tpauly@apple.com MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) Content-type: text/plain; charset=utf-8 From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Sat, 05 Mar 2016 17:49:35 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <1913628F357D497DABAB6D43640A02A7@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FAYobuh53aYwZ3NPBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsw5X1kLJitVHLraydbAeFq6i5GTQ0LAROLBmiUsELaYxIV7 69m6GLk4hAT2MkpsXbyIBaZoWitMYhmTxLJnPYwQTiOTxLpPbUBVHBzCAhISm/ckgjQICzhJ 3Fj5nAkkzCugL/HrTDiIySygLjFlSi5IBZuAisTxbxuYIcbzSsxofwq2ilPATOLjgiVMIDaL gKrErR9bWUFsZgFDieX7NkPZ2hJP3l0As3kFbCQWzu5jgbjmNZNE45Ed7CAJEaDmm9t+Qi2Q lbhz/DRYkYTAGjaJh882Mk1gFJ2FcN4shPNmIVmxgJF5FaNQbmJmjm5mnpleYkFBTqpecn7u JkZQyE+3E93BeGaV1SFGAQ5GJR7elPLbYUKsiWXFlbmHGKU5WJTEee0/3AwTEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwLi8MsNB4spL5y1zH6V2dmzqWfrkzTLemWn/nAVidffLxLRZXjtk brfr2fc9H/YFhDLPXfMvuJmbJc9xZ9u0f6Vp2xYuM9l/ctF/m/bp6/vaH5paTnj9RtXoUe/h 1Q4Lt4qd7F99/LzVir0edle+h0Z8ey3pkPTq2R6O9MeBcg6nPvxO2vbk0q4jSizFGYmGWsxF xYkAiNawDFoCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRbCgO0N3QczvM4EETp8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXPOV9aCyUoVh652sjUwnpbuYuTkkBAwkZjWup4NwhaTuHAP xObiEBJYxiSx7FkPI4TTyCSx7lMbSxcjB4ewgITE5j2JIA3CAk4SN1Y+ZwIJ8wroS/w6Ew5i MguoS0yZkgtSwSagInH82wZmiPG8EjPan7KA2JwCZhIfFyxhArFZBFQlbv3YygpiMwsYSizf txnK1pZ48u4CmM0rYCOxcHYfC8Q1r5kkGo/sYAdJiAA139z2E2qBrMSd46dZJjAKzUK4aBbC RbOQTF3AyLyKUaAoNSex0lQvsaAgJ1UvOT93EyM4RAsjdjD+X2Z1iFGAg1GJh/fFs5thQqyJ ZcWVuYcYJTiYlUR4HTtvhwnxpiRWVqUW5ccXleakFh9iTAb6ZSKzlGhyPjB+8kriDU1MDEyM jc2Mjc1NzEkTVhLnNTlxNUxIID2xJDU7NbUgtQhmCxMHp1QDo9Y1s02uiey9Su92pyU/ErvQ Z/tFuy96zT6m/ZHBS3N/LlkjOVefO7BH6qX/k+JJ17+2rNXTFgisq9DIrm16elviScGGZRoX GF6w1Sdyd+lyWW+dlBAipXu06oYwY9qE3B/352ff1V7jUiH8u2Hm++pzl4qWuX8xFbvbwN// 2Xx6M49C/eMGJZbijERDLeai4kQAmyIAQZUCAAA= Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 01:49:38 -0000 > On Mar 5, 2016, at 5:11 AM, Valery Smyslov wrote: >=20 >> If there is no consensus about puzzles, perhaps we should leave that >> part out of the document? >=20 > I had an impression that threre was a consensus when > the document was adopted by WG. In any case, I think that it is better = to have an interoperable specification than to leave puzzles at all (and = thus make them a subject > for a proprietary solutions). I agree that interoperability is key, and having a definition is useful = if anyone will be implementing it.=20 >=20 >>> And note, that the way puzzles are used in the draft makes every >>> attempt to not discriminate those initiators that don't support = puzzles >>> or cannot afford enough power to solve them. In other words - >>> puzzles mechanism in the draft is not an absolute barrier for >>> unsupported clients, it is just a first-class ticket for those who = support and afford. >>=20 >> which is the botnet more than mobile phones. Which is why I don't see = I >> would implement this. It seems session resumption would be more >> effective at distinguishing returning clients from a botnet. >=20 > Sure. But before every client becomes a "returning" one it must pass = usual IKE_SA_INIT. And it cannot be a returning client the rest of its > life - it must be fully reauthenticated from time to time. > Thus the resumption cannot make the task of DDoS protection in = IKE_SA_INIT non-existent. Going along with Paul=E2=80=99s point, it does seem that the approach of = session resumption would favor the legitimate mobile-device client, = where the puzzle approach may unintentionally favor the botnets = themselves. But it is also a good point that session resumption alone = cannot solve the DDoS problem. Would it be possible, I wonder, to try to combine these approaches to = create a solution that has the responder-protecting properties of = puzzles, while still favoring legitimate clients? This would require = using some property of legitimate clients (who will be able to = successfully authenticate later in the negotiation) as part of the = puzzle-challenge, or a way to skew the results in their favor. I=E2=80=99m= not sure if this is possible from the algorithmic perspective, but it = would be interesting to use some pre-known value (a shared secret, an = initiator or responder ID, etc) as a key to the puzzle that, if known, = would allow a quicker solution. It should be impossible to tell what = this original key or salt is from an eavesdropper=E2=80=99s perspective, = but it could make the calculation quicker for a client with a weak = processor that was correctly provisioned to communicate with the server. Thanks, Tommy >=20 >>> Could you, please, elaborate what scenario do you have in mind? >>=20 >> If you have an IPsec server willing to talk IKE/IPsec to anonymous >> clients. So one-side AUTH_NULL, the other a real authentication. = Since >> the server talks to everyone who sends it an IKE_INIT,=20 >=20 > How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder > doesn't yet know that the initiator will use NULL auth or real auth, = so any server usually replies to everyone who sends IKE_SA_INIT request. >=20 >> it is important >> that this IKE_INIT reply is much smaller than the IKE_INIT request, >> so this does not become a new amplification target.=20 >=20 > IKE_SA_INIT reply in most cases is smaller than request. > The responder returns only a subset of initiator's SA transforms, a = subset of initiator's notifications (returning only supported ones), > and usually only a subset of VIDs. > In which real life scenario it is larger than request? >=20 >> Currently, such >> a server could only always require dcookies to accomplish this, but >> that takes an additional round trip. Some kind of padding in the >> IKE_INIT request could easilly prevent this. >=20 > Sorry, I failed to understand how additional padding would work. > Are you going to reject initiators that don't include this additional = padding > (i.e. - all usual IKEv2 clients)? Am I missing something? >=20 > Regards, > Valery. >=20 >> Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Mar 6 02:29:29 2016 Return-Path: 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 5E8C01A87EB for ; Sun, 6 Mar 2016 02:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 5f7HJB40u_5L for ; Sun, 6 Mar 2016 02:29:24 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279551A89EB for ; Sun, 6 Mar 2016 02:29:23 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id k15so102765881lbg.0 for ; Sun, 06 Mar 2016 02:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :importance; bh=3vnHV4AA4aepe+IJVf64AjQ+EAnMqrVqieQdSKAMDe4=; b=0UUUbeVRdodg6w5dCvqTq73NkBT7uIp0UN1dmM/HYUpGvBjgS3OLSOHTfKDKgoV0I+ Dmvwd+Y4W6uJr/ht2VdkS/SfCmycJSb/nKpnUfwfTY1zy3LXqRnntvx/pOJ5TeJXoNxt rD1BsZ3pN3OXAGVGvF7VxUOHeJgvLECrIkwBBpg9AxA4eYWar3v5IVuEuvo2hZuUXEBy 0NKuX9vQR9yCAb0alpgVFHjirQiw3jMfwyb9o71PvgcWlLNG+4DsR0Pms2XuULMmSR/D y/tbo7ITRLgSpwbvMFN/gxbrJsFAcPr3BIE28qwu7WuXZHLS5tqEL9ZWvqp1+uC40jwz 4W+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:importance; bh=3vnHV4AA4aepe+IJVf64AjQ+EAnMqrVqieQdSKAMDe4=; b=DtV/UK8TChO8NeSJ7Hg0YxWvR/Wgfev10sUWeoQObibc/7+CDJc11rhqFKNs1Yghv1 KmQsGmWqfFUymlSpLCoqb6wvP3TEM3LPpVqnquSPFk/m4JczMM+O1nbHc4cOE1Dwkem3 D8h1WOnsqJybNGqMRE41bQfvvSm2LDmSnAjXsmRF9j516zvr6M9wLx5bqfX+cmxg0cD5 +2sH6oyi14N64BZEBwpcDKRZ8KGQXensETCtxMf26mU6eYi1vQDSXcdW8HHIzyge/DLm 4JPsxqyKVCc28xNVmXpmhohcrIGMx+u4BUiH9koABQviDutsFx1L4/Wsh9OHX2de/jKS l15A== X-Gm-Message-State: AD7BkJL0rYEro1P7fnY5V175hF3ofaJs+3YWNzhcR7915cjOWvcm7n9fNeqR7n6fsasNYQ== X-Received: by 10.112.54.201 with SMTP id l9mr5999872lbp.105.1457260161169; Sun, 06 Mar 2016 02:29:21 -0800 (PST) Received: from chichi (ppp83-237-34-31.pppoe.mtu-net.ru. [83.237.34.31]) by smtp.gmail.com with ESMTPSA id mi9sm1925888lbc.27.2016.03.06.02.29.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Mar 2016 02:29:20 -0800 (PST) Message-ID: <2AEEC861EA794086B94EED247892A7E8@chichi> From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <81FF76AD3936477D913A27BED694E464@buildpc> In-Reply-To: Date: Sun, 6 Mar 2016 13:29:13 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01D177AC.2CBCB560" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 10:29:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01D177AC.2CBCB560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Scott, please see inline. ppk_indicator =3D PRF(PRF(ppk, "A"), ppk_indicator_input) =20 This proposal has the following advantages. 1. Reusing existing IKEv2 registry 2. Better interoperability, since the PRF transform is mandatory in the = SA payload in IKEv2 and the responder can always be sure that the chosen PRF is = supported by the initiator. With the current proposal the situation is = possible when=20 the initiator includes, for example, only AEAD transforms in SA = payload. In this case even AEAD transform is (for example) AES based, there = is no guarantee that plain AES encryption is also supported by the initiator. 3. The current PPK Indicator Algorithm field combines 2 algorithms - = encryption and prf. Actually, it doesn=E2=80=99t =E2=80=93 it only implements the = =E2=80=9CPPK hint=E2=80=9D algorithm. I meant that in your proposal the =E2=80=9CPPK hint=E2=80=9D algorithm = uses two crypto primitives =E2=80=93 a cipher (AES) and a prf (HMAC_SHA256). I=E2=80=99d rather get rid of cipher and redefine the =E2=80=9CPPK = hint=E2=80=9D algorithm using sole prf (as shown above). Why do I want this? Because it would allow to reuse an existing IKEv2 registry=20 that defines Transforms of Type PRF. Why is it important for me?=20 Currently you defined the only value for =E2=80=9CPPK hint=E2=80=9D = algorithm -=20 AES256+HMAC_SHA256. If additional values are defined, then the responder will have to decide what algorithm to choose talking with particular initiator. One (and probably the most important) of selection criterias is the following: the algorithm must be mutually = supported=20 by the initiator and the responder. In your current proposal there is no = explicit=20 indication from the initiator which algorithms it supports and the = responder will need to use a heuristics (for example, if the initiator proposes = using AES-GCM for an encryption, does it mean that AES-ECB is also supported? It may sound silly, but I can imagine the situation when AES-GCM is supported, while AES-ECB =E2=80=93 not, for example if all crypto is = performed in dedicated hardware). Redefining =E2=80=9CPPK hint=E2=80=9D algorithm = to use sole PRF would allow the responder to have explicit and reliable information when choosing the mutually supported algorithm: it is the list of PRFs present in the initiator=E2=80=99s SA payload. =20 Once more algorithms are supported as PPK indicator the size of the registry will be grown quickly since every new prf will be = combined with every new cipher (yes, it can be limited by combining only selected prfs with only selected ciphers, but that would reduce = interoperability). I would personally be surprised if there are any more algorithms added = to the registry. The current algorithm works quite well, if we believe = that AES is even slightly secure. The only reason I could see if = someone asked for something new is if they had issues actually = implementing AES. =20 >From my point of view there are two main reasons for defining additional = algorithms, both quite real. First, some countries have a legacy restrictions on = using non-government approved crypto algorithms in some situations. For example, here in Russia you = must use only GOST if you=20 make products for government structures. Second, some constrained = devices may implement very limited set of crypto primitives, and it doesn=E2=80=99t necessary = includes AES and SHA2.=20 As an implementer I don=E2=80=99t want to waste resources (both = device=E2=80=99s and human) to add AES and SHA2=20 to them if it is possible to reuse existing crypto. =20 This would make the idea of precomputing ppk indicators on responder less efficient (you may easily precompute the whole ppk database = using few popular PRFs, but if these PRFs are combined with ciphers -=20 the resulting number of their combinations could become too big). With my idea, if you support only one PPK indicator algorithm, you need = to precompute each PPK once (if the server fixes the PPK indicator = input). With your idea, you=E2=80=99d need to redo it for every PRF you = support. How is this an advantage for your idea? =20 It is a local matter of responder how it manages its PPKs. I can see at = least three possible approaches. The first one =E2=80=93 the responder may choose not to = precompile PPK hints at all. It is the worst case in terms of consuming its CPU power, but it would = allow the server to use random data for each initiator, thus completely = protecting their privacy. Second approach =E2=80=93 as you suggest, when the responder fixes the = PPK indicator input for some perion of time and then precompiles PPK hints for all the = supported PRFs. You are right - the more PRFs it supports the more resources it consumes = while precompiling.=20 Both approaches are trivial. I=E2=80=99d envision third approach, which is a combination of the two. = The responder needs not to precompile hints beforehand. When it receives a PPK hint from the = initiator it starts searching for the PPK by applying =E2=80=9CPPK hint=E2=80=9D = algorithm to every PPK, as in the first approach, until the correct PPK is found. However, the responder saves = every usuccessful result in a PPK hint cache, so that when the next client appears, the cache is = consulted first and only if the PPK is not found via the cache, the responder continues to = search remaining PPKs with PPK algorithm. This approach allows the responder not to waste = resources precompiling the hints for every PPK it has and every PRF it supports if = some PPKs and PRFs are not used during the lifetime of the PPK indicator input. I think this approach would mitigate the need to spend more resources in = case of several PRFs are supported. =20 I see the only disadvantage of this proposal. As you wrote you = specifically used combination of encryption and PRF since AES is supported in = hardware=20 on some CPUs and thus gives some performance advantages over PRF-only scheme. I don't think it is a compelling argument. =20 Actually, I would argue that it is. One complaint I=E2=80=99ve heard is = that this would require the server to scan through its list of = PPK=E2=80=99s for every session it gets. The current draft allows a = server to reissue PPK indicator inputs to reduce this impact; however we = would prefer servers to reissue PPK indicator inputs are rarely as = possible. Making the evaluation of the PPK algorithm cheaper encourages = implementations to do this. =20 That=E2=80=99s true. The question is whether what is = =E2=80=9Ccheaper=E2=80=9D today will still be =E2=80=9Ccheaper=E2=80=9D = tomorrow=20 (and please multiple this by the number of HW platforms that exists in = the world). =20 It reflects only the current situation in the industry and may change over time. =20 It may, but likely won=E2=80=99t. Intel has announced hardware support = for accelerating SHA-1 and SHA-256; however I believe that even with = that support, one AES-NI evaluation of AES-256 will be faster than two = evaluations of the block compression of either SHA-1 or SHA-256 = (assuming the PRF is either HMAC-SHA1 or HMAC-SHA256) =20 Sorry, I can=E2=80=99t buy this. Intel is not the only CPU manufacturer = out there. And don=E2=80=99t forget about dedicated crypto hardware. I=E2=80=99d like to see a generic solution not based on momentary trends = in the industry. =20 I don't think the protocol should be based on such shaky grounds. Am I missing something? =20 >From where I stand, it would appear that the main advantage of your = proposal is =E2=80=9Cwe won=E2=80=99t have to ask IANA for another = registry=E2=80=9D. Am I missing something? Mostly, however that=E2=80=99s a bit oversimplified. Reusing existing = registry is not the most important advantage per ce,=20 it would just allow to get other advantages, like better = interoperability when more PPK algorithms are defined, reusing of existing code for parsing PRF transform in SA payload, = easying the procedure of adding new PPK algorithms (once new PRF is added by IANA it automatically can be = used in PPK hint algorithm) and so on. By the way, it even decreases the size of PPK_REQUEST notification by 2 = bytes! :-) =20 Regards, Valery. =20 =20 Few editorial issues: =20 1. Abstract No point at the end of the abstract. =20 2. Section 1 [The general idea is that we add an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2.] s/in addition/an addition ?=20 =20 3. IANA Considerations section is missing. =20 Regards, Valery Smyslov. =20 =20 =20 =20 Last year, NSA made an announcement about how to deal with the = potentiality of someone developing a Quantum Computer; = (https://www.nsa.gov/ia/programs/suiteb_cryptography/). Among their = recommendations was the advice that: =20 =E2=80=9CCSfC deployments involving an IKE/IPsec layer may use RFC = 2409-conformant implementations of the IKE standard (IKEv1) together = with large, high-entropy, pre-shared keys and the AES-256 encryption = algorithm. RFC 2409 is the only version of the IKE standard that = leverages symmetric pre-shared keys in a manner that may achieve quantum = resistant confidentiality. =20 The reason they gave this advise was the IKEv1, unlike IKEv2, stirred = in the preshared key into the KDF function (along with the (EC)DH shared = secret); hence if the preshared key was strong, then Shor=E2=80=99s = algorithm (which can recover the (EC)DH shared secret) is not enough to = recover the negotiated keys. =20 Now, we don=E2=80=99t want people to migrate back to an obsolete = version of the protocol; hence we=E2=80=99ve devised a way to strengthen = IKEv2 the same way. =20 It was considered important to minimize the changes made to IKEv2. = >From a cryptographical prespective, the only change we make is that we = modify the nonces that we present to the KDF. By keeping the = cryptographical changes minimal, we reduce the risk of accidentally = introducing a weakness. =20 Like IKEv1, this solution assumes that the initiator and the responder = share a secret string (called a PPK in the draft). However, unlike = IKEv1, that is not the only authentication that=E2=80=99s in the system. = We leave the existing authentication methods in place, and add this in = addition. =20 One thing that was a source of complexity was that we did not want to = assume that every system had the same PPK; that instead that systems = would want a pairwise PPK. However, if a responder configured its PPK = on a per-peer basis, and didn=E2=80=99t learn the peer until after an = IKEv2 tunnel has been established, that would mean that the responder = would need to know the PPK before it officially learned the peer. To = solve this, we added the PPK_REQUEST/PPK_ENCODE notifications to give = the responder a hint about which PPK to use (without leaking the = identity to third parties). =20 =20 Would anyone be willing to review this draft? I believe that we have = a need for such a solution. -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0005_01D177AC.2CBCB560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Scott,
 
please see inline.

ppk_indicator =3D=20 PRF(PRF(ppk, "A"), ppk_indicator_input)

 

This = proposal=20 has the following advantages.

1. = Reusing=20 existing IKEv2 registry

2. = Better=20 interoperability, since the PRF transform is mandatory in the SA=20 payload

   =20 in IKEv2 and the responder can always be sure that the chosen PRF is=20 supported

   =20 by the initiator. With the current proposal the situation is possible = when=20

   =20 the initiator includes, for example, only AEAD transforms in SA=20 payload.

   =20 In this case even AEAD transform is (for example) AES based, there is no = guarantee

   =20 that plain AES encryption is also supported by the = initiator.

3. The = current=20 PPK Indicator Algorithm field combines 2 algorithms - = encryption

   =20 and prf.

Actually, it = doesn=E2=80=99t =E2=80=93 it only=20 implements the =E2=80=9CPPK hint=E2=80=9D algorithm.

 

I meant that in=20 your proposal the =E2=80=9CPPK hint=E2=80=9D algorithm uses = two

crypto=20 primitives =E2=80=93 a cipher (AES) and a prf = (HMAC_SHA256).

I=E2=80=99d=20 rather get rid of cipher and redefine the =E2=80=9CPPK hint=E2=80=9D=20 algorithm

using=20 sole prf (as shown above). Why do I want this?

Because=20 it would allow to reuse an existing IKEv2 registry =

that=20 defines Transforms of Type PRF. Why  is it important for me?=20

Currently you defined the only value for =E2=80=9CPPK = hint=E2=80=9D algorithm -=20

AES256+HMAC_SHA256. If additional values are defined,=20 then

the=20 responder will have to decide what algorithm to = choose

talking=20 with particular initiator. One (and probably the most=20 important)

of=20 selection criterias is the following: the algorithm must = be mutually=20 supported

by the=20 initiator and the responder. In your current proposal there is no = explicit=20

indication from the initiator which algorithms it = supports and the=20 responder

will=20 need to use a heuristics (for example, if the initiator proposes = using

AES-GCM=20 for an encryption, does it mean that AES-ECB is also=20 supported?

It may=20 sound silly, but I can imagine the situation when AES-GCM=20 is

supported, while AES-ECB =E2=80=93 not, for example if = all crypto is=20 performed

in=20 dedicated hardware). Redefining =E2=80=9CPPK hint=E2=80=9D algorithm to=20 use

sole=20 PRF would allow the responder to have explicit and=20 reliable

information when choosing the mutually supported=20 algorithm:

it is=20 the list of PRFs present in the initiator=E2=80=99s SA = payload.

 

Once = more=20 algorithms are supported as PPK indicator the size

   =20 of the registry will be grown quickly since every new prf will be=20 combined

   =20 with every new cipher (yes, it can be limited by combining = only

   =20 selected prfs with only selected ciphers, but that would reduce=20 interoperability).
I would personally be surprised if there are = any more=20 algorithms added to the registry.  The current algorithm works = quite well,=20 if we believe that AES is even slightly secure.  The only reason I = could=20 see if someone asked for something new is if they had issues actually=20 implementing AES.

 

From my=20 point of view there are two main reasons for defining additional=20 algorithms,

both=20 quite real. First, some countries have a legacy restrictions on using=20 non-government approved

crypto=20 algorithms in some situations. For example, here in Russia you must use = only=20 GOST if you

make=20 products for government structures. Second, some constrained devices may = implement

very=20 limited set of crypto primitives, and it doesn=E2=80=99t necessary = includes AES and=20 SHA2.=20

As an=20 implementer I don=E2=80=99t want to waste resources = (both = device=E2=80=99s and human) to add=20 AES and SHA2

to them=20 if it is possible to reuse existing crypto.

 

   =20 This would make the idea of precomputing ppk indicators on = responder

   =20 less efficient (you may easily precompute the whole ppk database using=20 few

   =20 popular PRFs, but if these PRFs are combined with ciphers -

   =20 the resulting number of their combinations could become too=20 big).

With my idea, if you = support=20 only one PPK indicator algorithm, you need to precompute each PPK once = (if the=20 server fixes the PPK indicator input).  With your idea, = you=E2=80=99d need to redo=20 it for every PRF you support.  How is this an advantage for your=20 idea?

 

It is a=20 local matter of responder how it manages its PPKs. I can see at least = three=20 possible

approaches. The first one =E2=80=93 the responder may = choose not to=20 precompile PPK hints at all.

It is=20 the worst case in terms of consuming its CPU power, but it would=20 allow

the=20 server to use random data for each initiator, thus completely protecting = their=20 privacy.

Second=20 approach =E2=80=93 as you suggest, when the responder fixes the PPK=20 indicator

input=20 for some perion of time and then precompiles PPK hints for all the = supported=20 PRFs.

You are=20 right - the more PRFs it supports the more resources it consumes while=20 precompiling.

Both=20 approaches are trivial.

I=E2=80=99d=20 envision third approach, which is a combination of the two. The = responder needs=20 not

to=20 precompile hints beforehand. When it receives a PPK hint from the=20 initiator

it=20 starts searching for the PPK by applying =E2=80=9CPPK hint=E2=80=9D = algorithm to every PPK, as=20 in the first

approach, until the correct PPK is found. However, the = responder=20 saves every usuccessful result

in a=20 PPK hint cache, so that when the next client appears, the cache is = consulted=20 first and

only if=20 the PPK is not found via the cache, the responder continues to search=20 remaining

PPKs=20 with PPK algorithm. This approach allows the responder not to waste=20 resources

precompiling the hints for every PPK it has and every = PRF it=20 supports if some PPKs

and=20 PRFs are not used during the lifetime of the PPK indicator=20 input.

I think=20 this approach would mitigate the need to spend more resources in case of = several=20 PRFs are supported.

 

I see = the only=20 disadvantage of this proposal. As you wrote you specifically

used = combination=20 of encryption and PRF since AES is supported in hardware

on = some CPUs and=20 thus gives some performance advantages over PRF-only

scheme. I don't=20 think it is a compelling argument.

 

Actually, I would = argue that it=20 is.  One complaint I=E2=80=99ve heard is that this would require = the server to scan=20 through its list of PPK=E2=80=99s for every session it gets.  The = current draft=20 allows a server to reissue PPK indicator inputs to reduce this impact; = however=20 we would prefer servers to reissue PPK indicator inputs are rarely as=20 possible.  Making the evaluation of the PPK algorithm cheaper = encourages=20 implementations to do this.

 

That=E2=80=99s=20 true. The question is whether what is =E2=80=9Ccheaper=E2=80=9D today = will still be =E2=80=9Ccheaper=E2=80=9D=20 tomorrow

(and=20 please multiple this by the number of HW platforms that = exists in=20 the world).

 

It = reflects only=20 the current

situation in the=20 industry and may change over time.

 

It may, but likely = won=E2=80=99t. =20 Intel has announced hardware support for accelerating SHA-1 and SHA-256; = however=20 I believe that even with that support, one AES-NI evaluation of AES-256 = will be=20 faster than two evaluations of the block compression of either SHA-1 or = SHA-256=20 (assuming the PRF is either HMAC-SHA1 or = HMAC-SHA256)

 

Sorry,=20 I can=E2=80=99t buy this. Intel is not the only CPU manufacturer out = there. And don=E2=80=99t=20 forget about dedicated crypto hardware.

I=E2=80=99d=20 like to see a generic solution not based on momentary trends in the=20 industry.

 

I = don't think=20 the protocol

should = be based=20 on such shaky grounds. Am I missing something?

 

From where I stand, = it would=20 appear that the main advantage of your proposal is =E2=80=9Cwe = won=E2=80=99t have to ask IANA=20 for another registry=E2=80=9D.  Am I missing something?

 

Mostly,=20 however that=E2=80=99s a bit oversimplified. Reusing existing registry = is not the most=20 important advantage per ce,

it=20 would just allow to get other advantages, like better interoperability = when more=20 PPK algorithms are defined,

reusing=20 of existing code for parsing PRF transform in SA payload, easying the = procedure=20 of adding new

PPK=20 algorithms (once new PRF is added by IANA it automatically can be used = in PPK=20 hint algorithm) and so on.

By the=20 way, it even decreases the size of PPK_REQUEST notification by 2 bytes!=20 :-)

 

Regards,

Valery.

 

 

 

Few = editorial=20 issues:

 

1.=20 Abstract

   =20 No point at the end of the abstract.

 

2. = Section=20 1

  =20 [The general idea is that we add an additional secret that is=20 shared
   between the initiator and the responder; this = secret is=20 in addition
   to the authentication method that is already = provided within IKEv2.]

   =20 s/in addition/an addition ?

 

3. = IANA=20 Considerations section is missing.

 

Regards,

Valery = Smyslov.

 

 

 

 

Last year, NSA made an announcement about how to = deal with=20 the potentiality of someone developing a Quantum Computer; (https://www= .nsa.gov/ia/programs/suiteb_cryptography/). =20 Among their recommendations was the advice that:

 

=E2=80=9CCSfC = deployments involving an=20 IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE = standard (IKEv1) together with large, high-entropy, pre-shared keys = and the=20 AES-256 encryption algorithm. RFC 2409 is the only version of the IKE = standard=20 that leverages symmetric pre-shared keys in a manner that may achieve = quantum=20 resistant confidentiality.

 

The reason they gave this advise was the IKEv1, = unlike=20 IKEv2, stirred in the preshared key into the KDF function (along with = the=20 (EC)DH shared secret); hence if the preshared key was strong, then = Shor=E2=80=99s=20 algorithm (which can recover the (EC)DH shared secret) is not enough = to=20 recover the negotiated keys.

 

Now, we don=E2=80=99t want people to migrate back = to an obsolete=20 version of the protocol; hence we=E2=80=99ve devised a way to = strengthen IKEv2 the=20 same way.

 

It was considered important to minimize the = changes made to=20 IKEv2.  From a cryptographical prespective, the only change we = make is=20 that we modify the nonces that we present to the KDF.  By keeping = the=20 cryptographical changes minimal, we reduce the risk of accidentally=20 introducing a weakness.

 

Like IKEv1, this solution assumes that the = initiator and=20 the responder share a secret string (called a PPK in the draft).  = However, unlike IKEv1, that is not the only authentication = that=E2=80=99s in the=20 system.  We leave the existing authentication methods in place, = and add=20 this in addition.

 

One thing that was a source of complexity was = that we did=20 not want to assume that every system had the same PPK; that instead = that=20 systems would want a pairwise PPK.  However, if a responder = configured=20 its PPK on a per-peer basis, and didn=E2=80=99t learn the peer until = after an IKEv2=20 tunnel has been established, that would mean that the responder would = need to=20 know the PPK before it officially learned the peer.  To solve = this, we=20 added the PPK_REQUEST/PPK_ENCODE notifications to give the responder a = hint=20 about which PPK to use (without leaking the identity to third=20 parties).

 

 

Would anyone be willing to review this = draft?  I=20 believe that we have a need for such a solution.

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

------=_NextPart_000_0005_01D177AC.2CBCB560-- From nobody Sun Mar 6 07:28:07 2016 Return-Path: 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 39D221A017E for ; Sun, 6 Mar 2016 07:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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=-0.001, 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 NQq-8yN8_TOJ for ; Sun, 6 Mar 2016 07:28:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF001A016E for ; Sun, 6 Mar 2016 07:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6397; q=dns/txt; s=iport; t=1457278084; x=1458487684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KYmsONuuB8lAOOBxeoTtFlkJ8kt0KPZiDT9sgmPicxg=; b=X4CnprV6Pg40hNYPspoLRffyd3PXxPNSWmdFE96Ps/LoR410P3GW/jIQ ffXFdAyPEgGJV3NzZBleSsbj335HzWgJEjZ5+mGM5VwzLq7jaL0Q9LAey 5OwfwxeQh36NaYYiLjrMz+dCKcNPMxj0r6zrD4qqMocrnqJub70DGAqIm c=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgClS9xW/5hdJa1dgzqBPwa4JYITD?= =?us-ascii?q?oFphg8CgRs4FAEBAQEBAQFkJ4RCAQEEeRACAQgOOAIfESUCBAENBQ4Lh3QDErp?= =?us-ascii?q?GDYRHAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGF4Q9gj2CE4QkAQSNaIlCAYMRg?= =?us-ascii?q?WWHAYF1jnqHDIdIAR4BQ4IDGYFIaogHJRZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,546,1449532800"; d="p7s'?scan'208";a="78201897" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2016 15:28:03 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u26FS3QV001256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Mar 2016 15:28:03 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 6 Mar 2016 09:28:02 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Sun, 6 Mar 2016 09:28:03 -0600 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Paul Wouters Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCT0HkAAA9+PoAAKAIqgAACBo+AAANw9YAANxCAgA== Date: Sun, 6 Mar 2016 15:28:02 +0000 Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3540122881_28729176" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 15:28:06 -0000 --B_3540122881_28729176 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi The only case I could imagine that this could occur is if the Initiators Nonce and KE were purposely made very small and the Initiator did not perform any validation on this, sending it=B9s own reply where the KE and Nonce were considerably larger. I=B9ve seen an amplification attack, where an implementation (as a responder) would reply to a SA_INIT. If the responder did not receive a reply to its SA_INIT it would re-transmit either 3 or 5 times (can=B9t remember exactly). (this seemed to not conform to 2.1 retransmission timers.. cheers On 05/03/2016 13:11, "IPsec on behalf of Valery Smyslov" wrote: >IKE_SA_INIT reply in most cases is smaller than request. >The responder returns only a subset of initiator's SA transforms, >a subset of initiator's notifications (returning only supported ones), >and usually only a subset of VIDs. >In which real life scenario it is larger than request? --B_3540122881_28729176 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg0XXW 1NShiu1ikIJC4xl1nS1XrqnzZX1DVLnHSRf/4EAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzA2MTUyODAxWjANBgkqhkiG9w0BAQEFAASCAQCU1vsr cRp5Jq3S1W9VIztHmWIOgDnJZT2xj59xzjKqdPQ9kfQBmeEutND4BrpbEwW53vD8I+MIsi/N ShJCMTY6yaSzaobkmmZKc2XUfs7Gz7dCG5OkKHUKmFl+z7e+kKvsvXpQFXdN27ytj1FtXjsK TyUVoTTVCeTxyEU5QocrLYat83B2tkcutVCVTnjDmjhu/cvyUroDsJ5fkpOiuqoZCAl+PyoA yR5nRuvKmwEnxJwkVFFpIv4GVqBVjEZmHN0Q5GQnly7fpAT9YJdGieEAcQsItY4wFYsd/ay7 jVztWVnADCwjqEv0ic6pC+xun9My11jbAQA1h/HZ362Uz+0R --B_3540122881_28729176-- From nobody Sun Mar 6 09:09:55 2016 Return-Path: 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 5B4F51B2F44 for ; Sun, 6 Mar 2016 09:09:54 -0800 (PST) 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 Ub0BOLfEMNex for ; Sun, 6 Mar 2016 09:09:53 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57351B2F45 for ; Sun, 6 Mar 2016 09:09:52 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id l68so45585581wml.1 for ; Sun, 06 Mar 2016 09:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Eh39fb6Z0lmryrnRDIk36+5runMThzFrtbOHIqPwlgI=; b=WLSy6dNAXbVaT74MVISLmK9uEb17Wrunydg/kcgp/aNpVJsm2rsP5QaZc+IK0Ljkob 5TH1o91CuYdV43KJAgVuCwsUEEDTk12kpzMR32irkEcZeZJevsRfrpNLl1b2JCLlwrKe oPCszDAPVxbHd8aySFkdjThdWRjSFL/SzpL86MHlq/+l4b29Vyk4s320oFFV+IF2tWjp qoHZp9sytkYNOgsVxmoF/CNaMikCE7Nf9yxyzLiRangKcPsr54rw0kcEX4728bVo4vu1 J/8ZVgOH7q74M+oFAVMFR7derTBRhFJSNgf9zD4XTgkeTOgSR1Uu50U8ENyyxlHritpA kyBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Eh39fb6Z0lmryrnRDIk36+5runMThzFrtbOHIqPwlgI=; b=VUZ7ufgu1YQvgXSFPYSsyDAQwVAo+d7qLBGoXT3UoTq3YGhG8Egy7GpVzYmWRM1rTF Ezayyvhwczma7QW8O37ntkaEQWw7mqrek5AMpPcKJcC0W6lqD5tg1Iq9BAnbH+3pV8WC Bq5GBBxwh4HTpyMQEeLTebM82/ZIq2krx12lhaAIUVHL1u2bZfempRIO1Po0s+TMsrJh agQ+Gm3t3AxBD9uZXQvIWtzoERy4A3GmlJ2lhWPfHeHwkYEPkOHkWsrUITW9tezPZMuA GuhGRXD27O0O0dx7LsLjF4yTWmk4OFu3mwNEqLjlOsM7vpVIJ+gNgo9AKnPMiCuvtrff 49CA== X-Gm-Message-State: AD7BkJKxKLA2bswhYALzv348WYoe/eYZu/OyZIUAMxCe/Ny1PNk3chZV6msuM1uTkJZcFQ== X-Received: by 10.28.32.13 with SMTP id g13mr8535107wmg.13.1457284191243; Sun, 06 Mar 2016 09:09:51 -0800 (PST) Received: from yoavs-mbp-2.mshome.net ([109.253.216.171]) by smtp.gmail.com with ESMTPSA id i1sm13668796wjs.45.2016.03.06.09.09.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Mar 2016 09:09:50 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BA284A7F-97E2-42A1-A868-04657D773499"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: Date: Sun, 6 Mar 2016 19:09:46 +0200 Message-Id: <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> References: <1913628F357D497DABAB6D43640A02A7@chichi> To: "Graham Bartlett (grbartle)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 17:09:54 -0000 --Apple-Mail=_BA284A7F-97E2-42A1-A868-04657D773499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Mar 2016, at 5:28 PM, Graham Bartlett (grbartle) = wrote: >=20 > Hi >=20 > The only case I could imagine that this could occur is if the = Initiators > Nonce and KE were purposely made very small and the Initiator did not > perform any validation on this, sending it=C2=B9s own reply where the = KE and > Nonce were considerably larger. >=20 > I=C2=B9ve seen an amplification attack, where an implementation (as a > responder) would reply to a SA_INIT. If the responder did not receive = a > reply to its SA_INIT it would re-transmit either 3 or 5 times (can=C2=B9= t > remember exactly). (this seemed to not conform to 2.1 retransmission > timers.. It doesn=E2=80=99t conform. I think this was more common in IKEv1, but = I=E2=80=99m not sure why. Maybe because of the need to store a larger = state for Main Mode. In IKEv2 a Responder should only reply once, but store the reply for = retransmission in case the request is received again. IMHO even in that case this is not an interesting attack. We should be = worried about amplification attacks where little traffic causes a lot of = traffic, not a case where I send a 200-byte packet which results in a = 250-byte packet, and not even a 5 250-byte packets. Sending a request = and directing a server to send an entire movie in 4K quality using RTP = in an interesting amplification attack. Using a 10-Mbps uplink to = generate 12-Mbps of traffic is not. Yoav --Apple-Mail=_BA284A7F-97E2-42A1-A868-04657D773499 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW3GRbAAoJECXR4BOacZZUANAIAOInqivz521QUFgmftO1tXe2 MRvDjuRe7zOnDTJZuVUnVlASVCgGF/FPwFNHRq+KU0ThmoUwazazhZvUymcrZLRA VcwvvjluA1Jvq3c6cZdpl8jqolT+49Niif1IMPyrl80xzT3w3BPCCw1Rgku76xpq QJsnEyyXD/whzwnpl9DjCom1tYrwxzYGpcV81iIr6+k9LciOJHtOSth/YrpgJMvX vjyA4Fy1rP7tCWUD1NbRSQWL7uWA8629ZYxrGW5cf96yn+/O12/dsXF0fI9cJzjJ RKgRZMsIp7l7oZukENHkitHFLFUMu/qFJVfsAThJD63O3O18+b1Nkz/suKTZcqo= =CYNC -----END PGP SIGNATURE----- --Apple-Mail=_BA284A7F-97E2-42A1-A868-04657D773499-- From nobody Sun Mar 6 09:16:54 2016 Return-Path: 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 994AA1B2F4C for ; Sun, 6 Mar 2016 09:16:52 -0800 (PST) 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 X_Cuf_8xVp7E for ; Sun, 6 Mar 2016 09:16:51 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEDB1B2F4A for ; Sun, 6 Mar 2016 09:16:50 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id p65so80483184wmp.1 for ; Sun, 06 Mar 2016 09:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=44T8Ytc9lvhtXUpYSzGbyulzgvB82zAx9zG1psI5OfU=; b=uQy/nXNVPwQDniOiFyd1zVIRP52dey6xPS7dvGyJ81/Z3sANXh/ccib1aLtZ/l4JYz rZbTKyY+iAFyr0SwpqgDeyXaiNKkdNAzlGA4v3WOfqI1WkWl3hsMVoJEmTxe0EvzSe+z kcC2ruG/dtLWF5nV1y/tDO1rwB+sR3VEIYFUhkKOpgE5ZSRsIyaEATkCmm4HB9eaScci XnofVH4Wt312uFZznzW1FlPnzu7jSOQwTVbIgMT+nQt2/mpk/wdctkJCWC+otdCjy+bY 1NwpNk2jF81OZSHGr/86lQjsa+Ur83yITTPuoK35MCiTJm+hj0nLROcBGSrQVixQVMXe bRUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=44T8Ytc9lvhtXUpYSzGbyulzgvB82zAx9zG1psI5OfU=; b=ZPT65G3f4i9+ZKwD3oUmBZF87bEMpaGVNUP3AzWY98Ic5yxz8lp3pSPJDPCdRo3h/2 DgrfYlQ3KVFmX25QllbJFyoAzC0ZB0tgor/803IsezOl/+5nqUP09sCuqOPOTtzwSedB z6eV5hiKwsGWyC/42UVhPUbsm3sqccXLLFH+LfWltJQSeBgMBg98Pg3YUYi9smGzJLW4 jtMRM79OiJEcFl6OXmLBZ1WsUoy3eLEx0HDqAKsXe3TCbsWOjC8zM2svgD4C54kNCgbh GyIKAa9pkQMCizX7F7EiLR91CKg2OgT9vyyG9neY2gC/0i2L+qyJ1WAd+g52qgvCyZMd UrKA== X-Gm-Message-State: AD7BkJJdbGRxRD7t3GyWYfA1Jg0sk6/FUpb/4nx9pq5iBufyaMy3H+A8VOU55QrrVcGYcA== X-Received: by 10.194.62.179 with SMTP id z19mr19736373wjr.96.1457284609352; Sun, 06 Mar 2016 09:16:49 -0800 (PST) Received: from yoavs-mbp-2.mshome.net ([109.253.216.171]) by smtp.gmail.com with ESMTPSA id gg7sm13829574wjd.10.2016.03.06.09.16.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Mar 2016 09:16:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Sun, 6 Mar 2016 19:16:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org WG" , "Waltermire, David A. \(Fed\)" , Tommy Pauly Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 17:16:52 -0000 > On 4 Mar 2016, at 5:29 PM, Paul Wouters wrote: >=20 >> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) = wrote: >> All: >>=20 >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I = believe the draft is shaping up nicely, >> but needs additional review. To that end, this message starts a = Working Group Last Call (WGLC) for >> draft-ietf-ipsecme-ddos-protection-04. >>=20 >> The version to be reviewed is = https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt. >>=20 >> Please send your comments, questions, and edit proposals to the = WG mail list until March 18, 2015. If you >> believe that the document is ready to be submitted to the IESG = for consideration as a Standards Track RFC >> please send a short message stating this. >=20 > I think the document is well written with respect to DDOS. I like > everything except the puzzles. It seems a lot of complexity for > no gain, especially with the problem being that botnets are better > at puzzle solving then mobile phones who want to not drain their > batteries. I wish we had better numbers on the actual power of mobile phones. = It=E2=80=99s all a question of how many times they can perform = PRF-HMAC-SHA256 per second. Tommy? Regardless, FWIW I (with implementer hat on) would implement DDoS = puzzles. As the draft suggests, they would be used selectively and only = as a last resort. I also think that if we had IPsec everywhere as Paul = would like, DDoS attacks on IKE responders (which is basically all of = the Internet) would become much more attractive. As it is, with = IPsec-based remote access the VPN gateway is an attractive target, so we = should have more aggressive methods in our arsenal. Yoav From nobody Sun Mar 6 11:12:30 2016 Return-Path: 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 1096A1B3155 for ; Sun, 6 Mar 2016 11:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 3u8YP5TNqqiJ for ; Sun, 6 Mar 2016 11:12:24 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0100.outbound.protection.outlook.com [23.103.200.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC71E1B3153 for ; Sun, 6 Mar 2016 11:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q0bKximuV209y/kHo7KX6RisTxWEC2HahedBJ6kJ4ZI=; b=Ej6E1HmWZNVvmb0CIE+muDmFrM+6SZy1URLoNFtCCm4W91voUu6UsCt/xJ/oR0GIarKgdDbKR3H6KuGbyJz1lNCaQR+J38Lf6Xe6a6R0jTlHLL7c0FE2duy1S32R3Q3GgHtkUshmp7MTcmUv9+uCN3keDqBw6Gy3Oyjv8/libaE= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.427.16; Sun, 6 Mar 2016 19:12:16 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0427.019; Sun, 6 Mar 2016 19:12:16 +0000 From: "Waltermire, David A. (Fed)" To: "tpauly@apple.com" , Valery Smyslov Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCHPdIAAA9+PoAAAz2MAAABE/gAAAEUH4AAIW1KAAAgvecAACSki5A= Date: Sun, 6 Mar 2016 19:12:16 +0000 Message-ID: References: <7CC6BEAF37124C56930D7769EF7B9848@chichi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: apple.com; dkim=none (message not signed) header.d=none;apple.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: b4905fb9-14a8-4615-eaeb-08d345f33b81 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 5:XJivpXm3fgm6Y+ygfi7ma6d04dXv7phlbMKoSXd4pGCfsMF5bZpDhj+wGgH/1e/CHhnSThe8btuyNLd9bDQX4RlRKOqkqqKyq5aekgg4wa9slgSxdY5llhGuuJYwBdlLiqlFWj4Bo859NDvFLSzEnw==; 24:OLjZYBqD52zFaEe4wgu75C7qI0Fvo9JKMy5CoZQRLDCkqS7AKjnkAWw49NfypMT3V00nX5q8yy57r/lLawLvvpuEs0bto63Pr5sx0KkW8K8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(51444003)(164054003)(6116002)(86362001)(102836003)(3846002)(586003)(93886004)(1220700001)(1096002)(2950100001)(11100500001)(33656002)(2900100001)(15975445007)(77096005)(5008740100001)(345774005)(230783001)(54356999)(76176999)(50986999)(189998001)(66066001)(10400500002)(5003600100002)(40100003)(122556002)(92566002)(5002640100001)(87936001)(19580405001)(74316001)(3280700002)(76576001)(2501003)(4326007)(99286002)(3660700001)(2906002)(5001770100001)(19580395003)(81166005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2016 19:12:16.4298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2016 19:12:30 -0000 V2l0aCBteSBoYXQgb2ZmLCBJIGxpa2UgdGhlIGlkZWEgb2YgcmVvcmdhbml6aW5nIHRoZSBwdXp6 bGUgb3JpZW50ZWQgY29udGVudCBpbiB0aGUgZHJhZnQgdG8gYWZ0ZXIgdGhlIGN1cnJlbnQgc2Vj dGlvbiA0LTYgY29udGVudC4gSU1ITywgSSB0aGluayB0aGlzIGNvdWxkIGltcHJvdmUgdGhlIGZs b3cgYW5kIG9yZ2FuaXphdGlvbiBvZiB0aGUgZG9jdW1lbnQuDQoNCkRhdmUNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cGF1bHlAYXBwbGUuY29tIFttYWlsdG86dHBh dWx5QGFwcGxlLmNvbV0NCj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDA1LCAyMDE2IDg6MzggUE0N Cj4gVG86IFZhbGVyeSBTbXlzbG92IDxzdmFucnVAZ21haWwuY29tPg0KPiBDYzogWW9hdiBOaXIg PHluaXIuaWV0ZkBnbWFpbC5jb20+OyBpcHNlY0BpZXRmLm9yZzsgUGF1bCBXb3V0ZXJzDQo+IDxw YXVsQG5vaGF0cy5jYT47IFdhbHRlcm1pcmUsIERhdmlkIEEuIChGZWQpIDxkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292Pg0KPiBTdWJqZWN0OiBSZTogW0lQc2VjXSBXR0xDIG9uIGRyYWZ0LWlldGYt aXBzZWNtZS1kZG9zLXByb3RlY3Rpb24tMDQNCj4gDQo+IEhpIFZhbGVyeSwNCj4gDQo+IFJlc3Bv bnNlcyBpbmxpbmUuDQo+IA0KPiBUaGFua3MhDQo+IFRvbW15DQo+IA0KPiA+IE9uIE1hciA1LCAy MDE2LCBhdCAyOjAwIEFNLCBWYWxlcnkgU215c2xvdiA8c3ZhbnJ1QGdtYWlsLmNvbT4gd3JvdGU6 DQo+ID4NCj4gPiBIaSBUb21teSwNCj4gPg0KPiA+IHRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50 cy4NCj4gPg0KPiA+Pj4+IEkgdGVuZCB0byBhZ3JlZSB3aXRoIFBhdWwgdGhhdCBJIGZpbmQgaXQg dW5saWtlbHksIGZyb20gYW4NCj4gPj4+PiBpbXBsZW1lbnRvcuKAmXMgc3RhbmRwb2ludCwgdGhh dCBtYW55IEluaXRpYXRvcnMgd2lsbCBjaG9vc2UgdG8NCj4gPj4+PiBpbXBsZW1lbnQgdGhlIHB1 enpsZSBsb2dpYywgZXNwZWNpYWxseSBvbmVzIHRoYXQgYXJlIHJ1bm5pbmcgb24gbW9iaWxlDQo+ IGRldmljZXMuIEl0IGlzIHVubGlrZWx5IHRoYXQgdGhlIHBob25lcyB3aWxsIGJlIGFibGUgdG8g c29sdmUgdGhlIHB1enpsZXMgcXVpY2tseQ0KPiBlbm91Z2ggdG8gYmVhdCBvdXQgYm90bmV0cywg YW5kIGl0IHdvdWxkIGJlIGhhcmQgdG8ganVzdGlmeSB0aGUgYmF0dGVyeQ0KPiBjb25zdW1wdGlv biBuZWNlc3NhcnkuDQo+ID4+Pj4gVGhhdCBiZWluZyBzYWlkLCB0aGUgZG9jdW1lbnQgZG9lcyBh IHZlcnkgZ29vZCBqb2Igb2YgZXhwbGFpbmluZw0KPiA+Pj4+IHRoZSBwcm9ibGVtIHNwYWNlLCBh bmQgdGhlIG90aGVyIHBhcnRzIG9mIGl0cyBzb2x1dGlvbg0KPiA+Pj4+IChyYXRlLWxpbWl0aW5n IGFuZCBzdWdnZXN0aW5nIHNlc3Npb24gcmVzdW1wdGlvbikgbWFrZSBnb29kIHNlbnNlLg0KPiBQ ZXJoYXBzIHRoZXJlIGNhbiBiZSBtb3JlIGZvY3VzIG9uIGhvdyBhIHJlc3BvbmRlciBjYW4gYmVz dCBwcm90ZWN0IGl0c2VsZg0KPiBpZiBpbmRlZWQgdGhlIG1ham9yaXR5IG9mIGl0cyBjbGllbnRz IGRvIG5vdCBzdXBwb3J0IHB1enpsZXM/DQo+ID4NCj4gPiBTZWN0aW9ucyA0IC0gNiBkZXNjcmli ZSBtZWFzdXJlcyBvdGhlciB0aGFuIHB1enpsZXMgdGhhdCB0aGUgcmVzcG9uZGVyIGNhbg0KPiB1 c2UgdG8gZGVmZW5kIGl0c2VsZiBhZ2FpbnN0IEREb1MgYXR0YWNrLg0KPiA+IERvIHlvdSB0aGlu ayBpdCBpcyBub3QgZW5vdWdoPyBQdXp6bGVzIGFyZSBhIG5ldyB0aGluZywgdGhhdCdzIHdoeQ0K PiA+IG1vcmUgdGV4dCBpcyBuZWVkZWQgdG8gZXhwbGFpbiBob3cgdGhleSBhcmUgZml0IGludG8g dGhlIHByb3RvY29sLiBIb3dldmVyDQo+IHRoZSBkcmFmdCBpcyBub3Qgc29sZWx5IGFib3V0IHB1 enpsZXMsIGFuZCBJIHRoaW5rIGl0IGNvdmVycyBvdGhlciBkZWZlbmRpbmcNCj4gdGVjaG5pcXVl cyBpbiBzdWZmaWNpZW50IGRldGFpbHMuDQo+IA0KPiBQZXJoYXBzIGl0IHdvdWxkIGJlIHVzZWZ1 bCB0byByZWFycmFuZ2UgdGhlIHNlY3Rpb25zIHRvIGhpZ2hsaWdodCB0aGlzIG1vcmUNCj4gY2xl YXJseS4gVGhlIGZpcnN0IHNlY3Rpb24gYWJvdXQgYSBzb2x1dGlvbiBpcyBQdXp6bGVzIChzZWN0 aW9uIDMpLCBmb2xsb3dlZCBieQ0KPiBzZWN0aW9ucyA0LTYgd2hpY2ggY292ZXIgb3RoZXIgYXNw ZWN0cyBvZiBERG9TIGF2b2lkYW5jZSBzdHJhdGVnaWVzLCB3aGljaCBpcw0KPiB0aGVuIGZvbGxv d2VkIGJ5IGFuIGluLWRlcHRoIGV4cGxhbmF0aW9uIG9mIHRoZSBQdXp6bGVzIGluIHRoZSBwcm90 b2NvbA0KPiAoc2VjdGlvbnMgNy05KS4gU2luY2UgdGhlIG90aGVyIGFzcGVjdHMgYW5kIHNhbmR3 aWNoZWQgaW4gYmV0d2VlbiBzZWN0aW9ucw0KPiBwdXJlbHkgZm9jdXNlZCBvbiBwdXp6bGVzLCB0 aGUgZHJhZnQgcmVhbGx5IGZlZWxzIGxpa2UgaXQgaXMgYWJvdXQgcHV6emxlcy4gV2hhdA0KPiBp ZiB0aGUgb3RoZXIgYXBwcm9hY2hlcyB3ZXJlIG1vdmVkIGJlZm9yZSB0aGUgZmlyc3QgcHV6emxl cyBzZWN0aW9uLCBzbyB0aGUNCj4gZW50aXJlIHNlY3Rpb24gb24gcHV6emxlcyBjYW4gYmUgY29u dGlndW91cz8NCj4gDQo+ID4NCj4gPj4+PiBPbmUgcXVlc3Rpb24gb24gc2VjdGlvbiA3LjEuMjoN Cj4gPj4+Pg0KPiA+Pj4+IElmIHRoZSByZWNlaXZlZCBtZXNzYWdlIGNvbnRhaW5zIGEgUFVaWkxF IG5vdGlmaWNhdGlvbiBhbmQgZG9lc24ndA0KPiA+Pj4+IGNvbnRhaW4gYSBDT09LSUUgbm90aWZp Y2F0aW9uLCB0aGVuIHRoaXMgbWVzc2FnZSBpcyBtYWxmb3JtZWQNCj4gPj4+PiBiZWNhdXNlIGl0 IHJlcXVlc3RzIHRvIHNvbHZlIHRoZSBwdXp6bGUsIGJ1dCBkb2Vzbid0IHByb3ZpZGUgZW5vdWdo DQo+ID4+Pj4gaW5mb3JtYXRpb24gdG8gZG8gaXQuICBJbiB0aGlzIGNhc2UgdGhlIEluaXRpYXRv ciBTSE9VTEQgcmVzZW5kDQo+ID4+Pj4gSUtFX1NBX0lOSVQgcmVxdWVzdC4gIElmIHRoaXMgc2l0 dWF0aW9uIHJlcGVhdHMgc2V2ZXJhbCB0aW1lcywgdGhlbg0KPiA+Pj4+IGl0IG1lYW5zIHRoYXQg c29tZXRoaW5nIGlzIHdyb25nIGFuZCB0aGUgSUtFIFNBIGNhbm5vdCBiZQ0KPiA+Pj4+IGVzdGFi bGlzaGVkLg0KPiA+Pj4+DQo+ID4+Pj4gSSBhbSBjb25jZXJuZWQgdGhhdCB0aGUgc3VnZ2VzdGlv biBmb3IgdGhlIGluaXRpYXRvciByZWFjdGluZyB0bw0KPiBtYWxmb3JtZWQgSUtFX1NBX0lOSVQg cGFja2V0cyBpcyB0byBzZW5kIG1vcmUgdHJhZmZpYyB0byB0aGUgcmVzcG9uZGVyLg0KPiA+Pj4+ IFRoZSByZXNwb25kZXIgc2hvdWxkIG5vdCBsZWdpdGltYXRlbHkgc2VuZCBhIFBVWlpMRSBub3Rp ZmljYXRpb24NCj4gd2l0aG91dCBhIENPT0tJRSBub3RpZmljYXRpb24sIHNpbmNlIHRoaXMgd291 bGQgYmUgaW52YWxpZC4NCj4gPj4+PiBJZiB0aGUgaW5pdGlhdG9yIHNlZXMgdGhpcywgaXQgY2Fu IGVpdGhlciBhc3N1bWUgdGhhdCAoYSkgdGhlDQo+ID4+Pj4gcmVzcG9uZGVy4oCZcyBpbXBsZW1l bnRhdGlvbiBpcyBvdXQgb2Ygc3BlYywgb3IgKGIpIHNvbWUgbWFsaWNpb3VzDQo+ID4+Pj4gdGhp cmQgcGFydHkgaXMgZGVsaWJlcmF0ZWx5IG1vZGlmeWluZyB0aGUgdW5lbmNyeXB0ZWQgcGFja2V0 LiBJbg0KPiA+Pj4+IHRoZSBmaXJzdCBjYXNlLCB0cnlpbmcgdG8gc2VuZCB0aGUgSUtFX1NBX0lO SVQgYWdhaW4gd291bGQgYmUgaW4gdmFpbjsgaW4NCj4gdGhlIHNlY29uZCBjYXNlLCB3ZSBoYXZl IHByb3ZpZGVkIGEgd2F5IGZvciBhIHRoaXJkIHBhcnR5IHRvIGNhdXNlIGluaXRpYXRvcnMNCj4g dG8gc2VuZCBtb3JlIHRyYWZmaWMgdG8gdGhlIHJlc3BvbmRlciwgdGh1cyBwcm92aWRpbmcgYW4g YXR0YWNrIHZlY3Rvci4gV2hhdA0KPiBhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGlzPw0KPiA+Pj4+ DQo+ID4+PiBBIHByb3BlciByZXNwb25kZXIgd291bGQgbm90IHNlbmQgYSBtYWxmb3JtZWQgcGFj a2V0LiBBbiBhdHRhY2tlcg0KPiA+Pj4gY291bGQgc2VuZCBhIG1hbGZvcm1lZCByZXNwb25zZSBp bW1lZGlhdGVseSBhZnRlciB0aGUgaW5pdGlhdG9yIHNlbmRzDQo+IHRoZSByZXF1ZXN0LiBCeSB0 aGUgdGltZSB0aGUgaW5pdGlhdG9yIGdldHMgdGhlIHJlYWwgcmVzcG9uZGVy4oCZcyByZXNwb25z ZSwgaXQNCj4gaGFzIGxvc3Qgc3RhdGUuDQo+ID4+Pg0KPiA+Pj4gVGhhdCBpcyB3aHkgaXQgaXMg YWx3YXlzIGEgZ29vZCBpZGVhIChub3QganVzdCBpbiB0aGlzIGNvbnRleHQpIGZvciB0aGUNCj4g aW5pdGlhdG9yIHRvIGlnbm9yZSBtYWxmb3JtZWQgcmVzcG9uc2VzIHVudGlsIHRoZSB0aW1lb3V0 IGlzIHJlYWNoZWQuDQo+ID4+Pg0KPiA+PiBUaGF0IG1ha2VzIHNlbnNlLiBUaGUgd29yZGluZywg aG93ZXZlciwgY291bGQgaW1wbHkgdGhhdCB0aGUgSW5pdGlhdG9yDQo+IHNob3VsZCByZXNlbmQg dGhlIHJlcXVlc3QgYXMgaWYgaW4gcmVzcG9uc2UgdG8gdGhlIG1hbGZvcm1lZCBwYWNrZXQuDQo+ ID4+IEJhc2VkIG9uIHlvdXIgY29tbWVudCwgdGhlIEluaXRpYXRvciBzaG91bGQgd2FpdCBmb3Ig dGhlIHVzdWFsIGFtb3VudCBvZg0KPiB0aW1lIGJlZm9yZSByZXRyeWluZywgcmF0aGVyIHRoYW4g aW1tZWRpYXRlbHkgcmV0cnlpbmcgdGhlIHBhY2tldC4NCj4gPj4gSXQgbWF5IGJlIHVzZWZ1bCB0 byBjbGFyaWZ5IHRoaXMgaW4gdGhlIHRleHQuDQo+ID4NCj4gPiBZb3UgYXJlIHJpZ2h0IHRoYXQg dGhlIEluaXRpYXRvciBzaG91bGQgd2FpdCBmb3IgdGhlIHJldHJhbnNpc3Npb24gdGltZXIgdG8N Cj4gZXhwaXJlIGJlZm9yZSByZXNlbmRpbmcgbWVzc2FnZS4NCj4gPiBJIGFncmVlIHRoYXQgdGhl IHdvcmRpbmcgaXMgYW1iaWd1b3VzIGFib3V0IHRoYXQuIEhvdyBhYm91dCB0aGUNCj4gZm9sbG93 aW5nPw0KPiA+DQo+ID4gIElmIHRoZSByZWNlaXZlZCBtZXNzYWdlIGNvbnRhaW5zIGEgUFVaWkxF IG5vdGlmaWNhdGlvbiBhbmQgZG9lc24ndA0KPiA+IGNvbnRhaW4gYSBDT09LSUUgbm90aWZpY2F0 aW9uLCB0aGVuIHRoaXMgbWVzc2FnZSBpcyBtYWxmb3JtZWQgYmVjYXVzZQ0KPiA+IGl0IHJlcXVl c3RzIHRvIHNvbHZlIHRoZSBwdXp6bGUsIGJ1dCBkb2Vzbid0IHByb3ZpZGUgZW5vdWdoDQo+ID4g aW5mb3JtYXRpb24gdG8gZG8gaXQuICBJbiB0aGlzIGNhc2UgdGhlIEluaXRpYXRvciBNVVNUIGln bm9yZSAgdGhlDQo+ID4gcmVjZWl2ZWQgbWVzc2FnZSBhbmQgY29udGludWUgdG8gd2FpdCB1bnRp bCBlaXRoZXIgdGhlIHZhbGlkIG9uZSAgaXMNCj4gPiByZWNlaXZlZCBvciB0aGUgcmV0cmFuc21p c3Npb24gdGltZXIgZmlyZXMuIElmIGl0IGZhaWxzIHRvIHJlY2VpdmUgdGhlDQo+ID4gdmFsaWQg IG1lc3NhZ2UgYWZ0ZXIgc2V2ZXJhbCByZXRyYW5zbWlzc2lvbnMgb2YgSUtFX1NBX0lOSVQgcmVx dWVzdCwNCj4gPiB0aGVuICBpdCBtZWFucyB0aGF0IHNvbWV0aGluZyBpcyB3cm9uZyBhbmQgdGhl IElLRSBTQSBjYW5ub3QgYmUNCj4gZXN0YWJsaXNoZWQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgaXMg bW9yZSBjbGVhciwgdGhhbmtzIQ0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBWYWxlcnkuDQo+ID4N Cj4gPj4gVGhhbmtzLA0KPiA+PiBUb21teQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJ UHNlY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBzZWMNCg0K From nobody Mon Mar 7 07:23:57 2016 Return-Path: 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 87EC31B42BC for ; Mon, 7 Mar 2016 07:23:56 -0800 (PST) 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 fhG5sk7WaR10 for ; Mon, 7 Mar 2016 07:23:54 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1696F1B42B9 for ; Mon, 7 Mar 2016 07:23:54 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id l68so91136210wml.0 for ; Mon, 07 Mar 2016 07:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=57gE1hQiUMQuUftsvAjpq+b6kwih+YvwhcIRC/0KR/E=; b=jw6yBjCBAOBFUTkpHKRoFnUFnPoDmhsIEu5pGLssdabflWmv84XmmMOXFipv034C6N NwlSWjOaUQCFI1zrqQhXOI1TlY6IijetzlO8dfRWCTJ3vRdgHBsOmmRpCk/JpkuOxZjJ CKv9p/W7UMyOAg2tRbyYyC0XQZlt5PEgaPAgdHHFDqSrQMviQcaSYoJGtvjAGZNQWePI LufMKyBZzgmogcNPoSEbbiKrBk9r4+zRyJXqL75zwSVNH0eBAG9T2KfKuJsXC9+Kg8rp n+JjYLrIgVmsgGBkCUrINHibVYD/Hu4WHarDdlEzD3PWnkuLBieOBj3fBbCtlHrhWAhZ Qfvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=57gE1hQiUMQuUftsvAjpq+b6kwih+YvwhcIRC/0KR/E=; b=M+CspL09FO+92YnC+Lb7mL+onFHbN86QecLjsDwqDK7r6UZYk3/RaR8CVGcbYuN2Qg qVcq0MIM/6zed10QHBtzMZ5ZXzhISwWdPHnu1VHrRBgMk7SswtFnm20qkxpQ1q9ubaIC IRBukBHT+0WFPSWUv8Y26ghfGtafmp/WlsGc2inXlNmjtUsZvxUCu0Gu8OXgzwffCqDA K6KoGeyo0w+Wm9pfqE2EDRX9vKg0geabakIv4V1rLKdMeL7y8UImmFlRLeTNaY/sarKj 580wpn9ZSd06CHRwj3k/77W5XCoA+YmU6lYV9AN+oSmqtiUWajJvw+ZWNdz2eZzao+Dk f94w== X-Gm-Message-State: AD7BkJKsoQ1vYAZiaqhSKbQbq4zaqRC1PMd9YUcIUsRH4pG2dIrdnGXrYy92MUMPtzUAx6lQn8dH3/3hWTR39w== MIME-Version: 1.0 X-Received: by 10.28.90.68 with SMTP id o65mr13067029wmb.70.1457364232528; Mon, 07 Mar 2016 07:23:52 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.78.199 with HTTP; Mon, 7 Mar 2016 07:23:52 -0800 (PST) In-Reply-To: <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> <5281C22F-97EE-4994-829E-1121BEDE8E36@apple.com> Date: Mon, 7 Mar 2016 15:23:52 +0000 X-Google-Sender-Auth: 0Orvp1jk3VVjQqUNV11OWhpLl5w Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a11452394636d3b052d770d3e Archived-At: Cc: IPsecME WG , Paul Wouters , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:23:56 -0000 --001a11452394636d3b052d770d3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 4, 2016 at 5:05 PM, Tommy Pauly wrote: > I would also like to see the draft for TCP encapsulation added as an item= , > since we=E2=80=99ve gotten a fair amount of support for it. I am supporting this item. > For the purposes of the charter, it may be good to have a broader > explanation of the goal=E2=80=94something to the effect that the working = group > should focus on making sure that IKEv2 can be deployed more universally b= y > taking into account limitations of various networks. Previous RFCs like I= KE > fragmentation have contributed to this; TCP encapsulation tries to solve > another set of problematic networks; and we can imagine that there may be > more to investigate, such as taking into account the limitations and > requirements of IoT networks, etc. > > Tommy > > > On Mar 1, 2016, at 12:32 PM, Paul Wouters wrote: > > > > S/mostly// > > > > Add IKE over tcp and DNS extensions for ikev2? > > > > Sent from my iPhone > > > >> On Mar 1, 2016, at 11:18, Paul Hoffman wrote: > >> > >> Greetings. We need to update our charter to reflect our current and > expected work. Dave and I propose the following text. Please let us know > within the next week if you have suggestions for changes. > >> > >> --Paul Hoffman and Dave Waltermire > >> > >> > >> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs), > >> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPse= c > is > >> widely deployed in VPN gateways, VPN remote access clients, and as a > >> substrate for host-to-host, host-to-network, and network-to-network > >> security. > >> > >> The IPsec Maintenance and Extensions Working Group continues the work = of > >> the earlier IPsec Working Group which was concluded in 2005. Its > purpose is > >> to maintain the IPsec standard and to facilitate discussion of > clarifications, > >> improvements, and extensions to IPsec, mostly to IKEv2. > >> The working group also serves as a focus point for other IETF Working > Groups > >> who use IPsec in their own protocols. > >> > >> The current work items include: > >> > >> IKEv2 contains the cookie mechanism to protect against denial of servi= ce > >> attacks. However this mechanism cannot protect an IKE end-point > (typically, > >> a large gateway) from "distributed denial of service", a coordinated > attack by > >> a large number of "bots". The working group will analyze the problem a= nd > >> propose a solution, by offering best practices and potentially by > extending > >> the protocol. > >> > >> IKEv2 utilizes a number of cryptographic algorithms in order to provid= e > >> security services. To support interoperability a number of mandatory-t= o- > >> implement (MTI) algorithms are defined in RFC4307. There is interest i= n > >> updating the MTIs in > >> RFC4307 based on new algorithms, changes to the understood security > >> strength of existing algorithms, and the degree of adoption of > previously > >> introduced algorithms. The group will revise RFC4307 proposing updates > to > >> the MIT algorithms used by IKEv2 to address these changes. > >> > >> There is interest in supporting Curve25519 and Curve448 for ephemeral > key > >> exchange in the IKEv2 protocol. The group will extend the > >> IKEv2 protocol to support key agreement using these curves and their > >> related functions. > >> > >> This charter will expire in August 2016. If the charter is not updated > before > >> that time, the WG will be closed and any remaining documents revert > back to > >> individual Internet-Drafts. > >> > >> > >> > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11452394636d3b052d770d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 4, 2016 at 5:05 PM, Tommy Pauly <tpauly@apple.com> wrote:
I would also like to see the= draft for TCP encapsulation added as an item, since we=E2=80=99ve gotten a= fair amount of support for it.

I am suppo= rting this item.
=C2=A0
For the = purposes of the charter, it may be good to have a broader explanation of th= e goal=E2=80=94something to the effect that the working group should focus = on making sure that IKEv2 can be deployed more universally by taking into a= ccount limitations of various networks. Previous RFCs like IKE fragmentatio= n have contributed to this; TCP encapsulation tries to solve another set of= problematic networks; and we can imagine that there may be more to investi= gate, such as taking into account the limitations and requirements of IoT n= etworks, etc.

Tommy

> On Mar 1, 2016, at 12:32 PM, Paul Wouters <paul@nohats.ca> wrote:
>
> S/mostly//
>
> Add IKE over tcp and DNS extensions for ikev2?
>
> Sent from my iPhone
>
>> On Mar 1, 2016, at 11:18, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>
>> Greetings. We need to update our charter to reflect our current an= d expected work. Dave and I propose the following text. Please let us know = within the next week if you have suggestions for changes.
>>
>> --Paul Hoffman and Dave Waltermire
>>
>>
>> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associat= ed RFCs),
>> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). = IPsec is
>> widely deployed in VPN gateways, VPN remote access clients, and as= a
>> substrate for host-to-host, host-to-network, and network-to-networ= k
>> security.
>>
>> The IPsec Maintenance and Extensions Working Group continues the w= ork of
>> the earlier IPsec Working Group which was concluded in 2005. Its p= urpose is
>> to maintain the IPsec standard and to facilitate discussion of cla= rifications,
>> improvements, and extensions to IPsec, mostly to IKEv2.
>> The working group also serves as a focus point for other IETF Work= ing Groups
>> who use IPsec in their own protocols.
>>
>> The current work items include:
>>
>> IKEv2 contains the cookie mechanism to protect against denial of s= ervice
>> attacks. However this mechanism cannot protect an IKE end-point (t= ypically,
>> a large gateway) from "distributed denial of service", a= coordinated attack by
>> a large number of "bots". The working group will analyze= the problem and
>> propose a solution, by offering best practices and potentially by = extending
>> the protocol.
>>
>> IKEv2 utilizes a number of cryptographic algorithms in order to pr= ovide
>> security services. To support interoperability a number of mandato= ry-to-
>> implement (MTI) algorithms are defined in RFC4307. There is intere= st in
>> updating the MTIs in
>> RFC4307 based on new algorithms, changes to the understood securit= y
>> strength of existing algorithms, and the degree of adoption of pre= viously
>> introduced algorithms. The group will revise RFC4307 proposing upd= ates to
>> the MIT algorithms used by IKEv2 to address these changes.
>>
>> There is interest in supporting Curve25519 and Curve448 for epheme= ral key
>> exchange in the IKEv2 protocol. The group will extend the
>> IKEv2 protocol to support key agreement using these curves and the= ir
>> related functions.
>>
>> This charter will expire in August 2016. If the charter is not upd= ated before
>> that time, the WG will be closed and any remaining documents rever= t back to
>> individual Internet-Drafts.
>>
>>
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> >
> _______________________________________________
> 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

--001a11452394636d3b052d770d3e-- From nobody Mon Mar 7 07:59:32 2016 Return-Path: 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 9F1B31B4354 for ; Mon, 7 Mar 2016 07:59:30 -0800 (PST) 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 WX2U9Ok7WjVr for ; Mon, 7 Mar 2016 07:59:28 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DD01B434F for ; Mon, 7 Mar 2016 07:59:28 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id p65so76030650wmp.0 for ; Mon, 07 Mar 2016 07:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RzcV8a3XNpdPPePWASwLT3ko0C6+DPjNW5JGzq8F+ss=; b=IAlJBNlE7736CW5urUTDC9At07j94nb6xX/DkgfWEp+D4zueAYKrf6sWBBYH7xyvZo vNTh/IZgiBTOTb1TKntgEQNj1U8pweRNW2aZWdpdMaI8zTpel6GO2Hp+s5BUD/94YNCs wyOU5r4nk6F4pQrS7NUKiZ5I10GCqIc7rNKntMaU8HntBWUv5VGGfIgvRfOHkQjsEUYd 8Edx2XetyQom20VQrBQ9PoNO2AuBj93tcdWxBEj2X+Gr0zpeyP1921KhLZhUK/+LTZ1l w79x1rqAt6aNDZcRXTUJZCWrCnsAmcnTbD7SJvd6f3fhqlvfM5CniKXzIp5Szr2oxQ1S wIog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RzcV8a3XNpdPPePWASwLT3ko0C6+DPjNW5JGzq8F+ss=; b=PNaQaKGGVdGdueUY9TpTDOGZ0IPDZMCK2dnA+IddILyx5bjX6v97PgV/C3DA8zd+12 v6AowRqKUGXdE5ZKYx9OE3gg97BmRbLkCFoADN2m7fUQaaUSx/TCBfGnnWYx1NAtguiw eCkh+/QxzEv1EmfyW+ZfuY35qSnXX5LKgAurqpjb6kS2xEWE9N+teWPySV1lwXxinz7f uLckdyAREDAn24Xv8dFZ2GHGQu/FYiS45B5N7Y2I9vziZIteXZ01Ppi4MEH4xu3L9uc3 AzWfoFNRL8zvKTlwpmAgk3aAk0TZhTvh+IrvQ+3ADyAhRbBt8t43RTC6iNflDhTI4MBg Rpuw== X-Gm-Message-State: AD7BkJLRF9BOUfMYOLeOGaVwER53q9ejcktbZJgwYhYdEufQy2kSCjpT2SeiJ/RrJ7OhY6U73nM9RScibelCKw== MIME-Version: 1.0 X-Received: by 10.28.90.68 with SMTP id o65mr13254457wmb.70.1457366366798; Mon, 07 Mar 2016 07:59:26 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.78.199 with HTTP; Mon, 7 Mar 2016 07:59:26 -0800 (PST) In-Reply-To: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> Date: Mon, 7 Mar 2016 15:59:26 +0000 X-Google-Sender-Auth: TTR6CxBXaz41Zghaq1OXqqw-2zA Message-ID: From: Daniel Migault To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1145239499cc34052d778c94 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:59:30 -0000 --001a1145239499cc34052d778c94 Content-Type: text/plain; charset=UTF-8 Hi, We would like to add the definition of YANG models for IKEv2 and IPsec as items of the charter. The intent of such models is to be able to provide configurations that are implementations independent. Of course IPsecme will be expected to provide feed backs/comments on the data model which does not require any YANG knowledge. YANG aspects will be validated by YANG tools/community. We will publish a draft that proposes a YANG model for IKEv2 by next week. Future drafts on for IPsec will be provided later too. BR, Daniel On Tue, Mar 1, 2016 at 4:18 PM, Paul Hoffman wrote: > Greetings. We need to update our charter to reflect our current and > expected work. Dave and I propose the following text. Please let us know > within the next week if you have suggestions for changes. > > --Paul Hoffman and Dave Waltermire > > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), > IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is > widely deployed in VPN gateways, VPN remote access clients, and as a > substrate for host-to-host, host-to-network, and network-to-network > security. > > The IPsec Maintenance and Extensions Working Group continues the work of > the earlier IPsec Working Group which was concluded in 2005. Its purpose is > to maintain the IPsec standard and to facilitate discussion of > clarifications, > improvements, and extensions to IPsec, mostly to IKEv2. > The working group also serves as a focus point for other IETF Working > Groups > who use IPsec in their own protocols. > > The current work items include: > > IKEv2 contains the cookie mechanism to protect against denial of service > attacks. However this mechanism cannot protect an IKE end-point (typically, > a large gateway) from "distributed denial of service", a coordinated > attack by > a large number of "bots". The working group will analyze the problem and > propose a solution, by offering best practices and potentially by extending > the protocol. > > IKEv2 utilizes a number of cryptographic algorithms in order to provide > security services. To support interoperability a number of mandatory-to- > implement (MTI) algorithms are defined in RFC4307. There is interest in > updating the MTIs in > RFC4307 based on new algorithms, changes to the understood security > strength of existing algorithms, and the degree of adoption of previously > introduced algorithms. The group will revise RFC4307 proposing updates to > the MIT algorithms used by IKEv2 to address these changes. > > There is interest in supporting Curve25519 and Curve448 for ephemeral key > exchange in the IKEv2 protocol. The group will extend the > IKEv2 protocol to support key agreement using these curves and their > related functions. > > This charter will expire in August 2016. If the charter is not updated > before > that time, the WG will be closed and any remaining documents revert back to > individual Internet-Drafts. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a1145239499cc34052d778c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

We would like to add the definition = of YANG models for IKEv2 and IPsec as items of the charter. The intent of such models is to be able to provide configurations that are implementations independent. Of course IPsecme will be expected to provide feed backs/comments on the data model which does not require any YANG knowledge. YANG aspects will be validated by YANG tools/community.

We will publish a draft that proposes a YANG model for IKEv2 by ne= xt week. Future drafts on for IPsec will be provided later too.

BR, =

Daniel


On Tue, Mar= 1, 2016 at 4:18 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings. We need to update our= charter to reflect our current and expected work. Dave and I propose the f= ollowing text. Please let us know within the next week if you have suggesti= ons for changes.

--Paul Hoffman and Dave Waltermire


The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),=
IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is<= br> widely deployed in VPN gateways, VPN remote access clients, and as a
substrate for host-to-host, host-to-network, and network-to-network
security.

The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is=
to maintain the IPsec standard and to facilitate discussion of clarificatio= ns,
improvements, and extensions to IPsec, mostly to IKEv2.
The working group also serves as a focus point for other IETF Working Group= s
who use IPsec in their own protocols.

The current work items include:

IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically,=
a large gateway) from "distributed denial of service", a coordina= ted attack by
a large number of "bots". The working group will analyze the prob= lem and
propose a solution, by offering best practices and potentially by extending=
the protocol.

IKEv2 utilizes a number of cryptographic algorithms in order to provide
security services. To support interoperability a number of mandatory-to- implement (MTI) algorithms are defined in RFC4307. There is interest in
updating the MTIs in
RFC4307 based on new algorithms, changes to the understood security
strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 proposing updates to the MIT algorithms used by IKEv2 to address these changes.

There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange in the IKEv2 protocol. The group will extend the
IKEv2 protocol to support key agreement using these curves and their
related functions.

This charter will expire in August 2016. If the charter is not updated befo= re
that time, the WG will be closed and any remaining documents revert back to=
individual Internet-Drafts.




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

--001a1145239499cc34052d778c94-- From nobody Tue Mar 8 05:45:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6622E12D6F8 for ; Tue, 8 Mar 2016 05:45:24 -0800 (PST) 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, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1b6SxeJdCMf for ; Tue, 8 Mar 2016 05:45:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 506FB12D6FE for ; Tue, 8 Mar 2016 05:45:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u28DiUkg022513 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Mar 2016 15:44:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u28DiT4W017145; Tue, 8 Mar 2016 15:44:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22238.55101.405169.92924@fireball.acr.fi> Date: Tue, 8 Mar 2016 15:44:29 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <1913628F357D497DABAB6D43640A02A7@chichi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min Archived-At: Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 13:45:24 -0000 Paul Wouters writes: > > I agree that puzzles is a controversal thing. However currently we have no > > better idea how at least to try to defend against powerful botnets. If you > > can come up with such an idea, you are very welcome. > > If there is no consensus about puzzles, perhaps we should leave that > part out of the document? I think it is good thing to have puzzles in there, even if we do not enable them now. > > And note, that the way puzzles are used in the draft makes every > > attempt to not discriminate those initiators that don't support puzzles > > or cannot afford enough power to solve them. In other words - > > puzzles mechanism in the draft is not an absolute barrier for > > unsupported clients, it is just a first-class ticket for those who support > > and afford. > > which is the botnet more than mobile phones. Which is why I don't see I > would implement this. It seems session resumption would be more > effective at distinguishing returning clients from a botnet. I think it is good idea to have the puzzles already defined, so if this really comes a problem and puzzles are needed, we already have solution for that in the specification, we simply need to roll on the new implementations :-) I would hope server side gatways would implement those, but most likely they would only be enabled when someone is really under big attack. Also modern mobile phones do have more power than home area switches, adsl routers, coffee pots and other internet of target devices. Those very low end devices have so little cpu power that people do not even care if they are protected or not, and generating huge botnets of them might be way to make DDoS attacks. Also even the desktop and laptops do not have that much more raw cpu power than modern mobile phones. Yes, doing puzzles do consume also energy on phones, but you simply need to do it once, and then you are through. Botnets need to use cpu power all the time to beat you. I.e. phone should be willing to use few seconds of full cpu power to create the VPN tunnel and then keep it up and running for the whole day. > >> Recently, I also thought about amplification attacks, which is not > >> covered by the document. For instance, legitimate clients could pad > >> their IKE_INIT Request as a way to tell the responder they are not just > >> using the responder to amplify a DDOS attack. I am thinking of making > >> that the default for some Opportunistic IPsec so it cannot be abused for > >> amplification. I'd like to see that added to the draft if possible. Or > >> if this document would not proceed, I would be tempted to write a draft > >> for this idea. > > > > Could you, please, elaborate what scenario do you have in mind? > > If you have an IPsec server willing to talk IKE/IPsec to anonymous > clients. So one-side AUTH_NULL, the other a real authentication. Since > the server talks to everyone who sends it an IKE_INIT, it is important > that this IKE_INIT reply is much smaller than the IKE_INIT request, > so this does not become a new amplification target. Currently, such > a server could only always require dcookies to accomplish this, but > that takes an additional round trip. Some kind of padding in the > IKE_INIT request could easilly prevent this. IKI_SA_INIT response and IKE_SA_INIT request are almost the same size, I do not think there is need for padding. The SAr1 will always be subset of SAi1, i.e., it is either same size or smaller. The KEr is same size as KEr. Nr can be selected so that it is same size as Ni, so there is no difference. Only thing that is in the response which is not in the request is the CERTREQ if you are using certificate based authentication, and that is few tens of bytes (unless you have large number of CAs). On the other hand request also usually have different notifications indicating features etc, and in most cases those notifications are only included in response only if they were also in the request. You do might want to limit of sending lots of different vendor IDs in the server, as those might make the packet bigger... IKEv1 is much different in this case, as if client sends one packet to server, the server will then reply back and will most likely retransmit its response back until it gets next packet from client, or until request times out, thus in IKEv1 it is easy to get amplification factor of ten (if servers retry limit is for example 10). -- kivinen@iki.fi From nobody Tue Mar 8 06:04:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8129312D71B for ; Tue, 8 Mar 2016 06:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IykTLZF7TjgA for ; Tue, 8 Mar 2016 06:04:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5C5D112D6FD for ; Tue, 8 Mar 2016 06:04:50 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u28E4i9T019072 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Mar 2016 16:04:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u28E4hOK017292; Tue, 8 Mar 2016 16:04:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22238.56315.949166.508540@fireball.acr.fi> Date: Tue, 8 Mar 2016 16:04:43 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 14:04:54 -0000 Yoav Nir writes: > > I=C2=B9ve seen an amplification attack, where an implementation (as= a > > responder) would reply to a SA=5FINIT. If the responder did not rec= eive a > > reply to its SA=5FINIT it would re-transmit either 3 or 5 times (ca= n=C2=B9t > > remember exactly). (this seemed to not conform to 2.1 retransmissio= n > > timers.. >=20 > It doesn=E2=80=99t conform. I think this was more common in IKEv1, b= ut I=E2=80=99m > not sure why. Maybe because of the need to store a larger state for > Main Mode. It was because IKEv1 did not specify request response pairs. Every message was fire and forget message, and the sender of the mssage was supposed to take care whether it reached the other end or not. See section 5.1 of RFC2408: ---------------------------------------------------------------------- When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Set a timer and initialize a retry counter. NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based o= n measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). 2. If the timer expires, the ISAKMP message is resent and the retry= counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE. ---------------------------------------------------------------------- > In IKEv2 a Responder should only reply once, but store the reply for > retransmission in case the request is received again. Yep. See section 2.1 of RFC7296. > IMHO even in that case this is not an interesting attack. We should > be worried about amplification attacks where little traffic causes a > lot of traffic, not a case where I send a 200-byte packet which > results in a 250-byte packet, and not even a 5 250-byte packets. > Sending a request and directing a server to send an entire movie in > 4K quality using RTP in an interesting amplification attack. Using a > 10-Mbps uplink to generate 12-Mbps of traffic is not.=20 The IKEv1 reflection attacks can be bad, as sending single packet, you can generate 10 packets to be sent over several tens of seconds. --=20 kivinen@iki.fi From nobody Tue Mar 8 14:56:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494C112D846 for ; Tue, 8 Mar 2016 14:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqd7YfDqn2kb for ; Tue, 8 Mar 2016 14:56:45 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322DF12D663 for ; Tue, 8 Mar 2016 14:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105347; q=dns/txt; s=iport; t=1457477805; x=1458687405; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p/lsFjOPKj5WMFJgrOJX6rqJdM5Hy4KkcYH7mgmpyeo=; b=dn1uHUtHp5B/i7Epxhcvx89/qr0Z+zroj4Jc5TT1Gfui2aXV3EZO6LNJ 3p0xLczrwpVbRBklloAbJqbQPd7njifxHythULdWE0GdAa5jweWFywhP9 6e/uqcM/44VOtH7yQCKl35ULqKC1tL5oJJi1vkVfLF6oDawT9a+7WZDT5 w=; X-Files: draft-ietf-ipsecme-ddos-protection-05.txt, smime.p7s : 72403, 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZDAA9WN9W/4kNJK1TBgODOlIsQQanN?= =?us-ascii?q?odlgV8BiVIOgWkhgjyDMgKBRjgUAQEBAQEBAWQnhEIBAQICDgwBDD4PBQ4CAgE?= =?us-ascii?q?IDgQbAxYCGQYRFw4CBA4FCQUNh3QDEg66IQ2ESQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQ0IBIYTg0R+gj2BRwYHAwEGAQIBAwICAhgQCwsMBwgHg2wFh1gDCoYDeYJ?= =?us-ascii?q?lgTSEAQUqAYMRgWVsbIIEgmRCgXWBZBY1g3mHOYEahw2HSAEeAUOBfgICBhSBS?= =?us-ascii?q?GqIRAEBBxcEAxZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,558,1449532800"; d="txt'?p7s'?scan'208";a="247116782" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2016 22:56:42 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u28MugaH005288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 22:56:42 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 16:56:41 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 16:56:41 -0600 From: "Graham Bartlett (grbartle)" To: Yoav Nir Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCT0HkAAA9+PoAAKAIqgAACBo+AAANw9YAANxCAgAADjbcAAHCyIwA= Date: Tue, 8 Mar 2016 22:56:41 +0000 Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> In-Reply-To: <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3540322597_35303867" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 22:56:51 -0000 --B_3540322597_35303867 Content-type: multipart/mixed; boundary="B_3540322596_35303241" --B_3540322596_35303241 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi I=B9ve updated the draft (attached). Please see section 6.2, where I describe a method to (potentially) pull your movie in 4k quality.. cheers On 06/03/2016 17:09, "Yoav Nir" wrote: >Sending a request and directing a server to send an entire movie in 4K >quality using RTP in an interesting amplification attack.=20 --B_3540322596_35303241 Content-type: text/plain; name="draft-ietf-ipsecme-ddos-protection-05.txt" Content-disposition: attachment; filename="draft-ietf-ipsecme-ddos-protection-05.txt" Content-transfer-encoding: base64 IAoKCgpJUFNlY01FIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBZLiBOaXIKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoZWNrIFBvaW50CkludGVuZGVkIHN0 YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVi4g U215c2xvdgpFeHBpcmVzOiBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVMVklTLVBMVVMKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLkJhcnRsZXR0CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1hcmNoIDgsIDIwMTYKCgogICAgICBQcm90ZWN0aW5nIEludGVy bmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCB2ZXJzaW9uIDIgKElLRXYyKQogICAgICAgSW1w bGVtZW50YXRpb25zIGZyb20gRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2UgQXR0YWNr cwogICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBzZWNtZS1kZG9zLXByb3RlY3Rpb24t MDUKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgaW1wbGVtZW50YXRp b24gYW5kIGNvbmZpZ3VyYXRpb24gYmVzdAogICBwcmFjdGljZXMgZm9yIEludGVybmV0IEtl eSBFeGNoYW5nZSBQcm90b2NvbCB2ZXJzaW9uIDIgKElLRXYyKQogICBSZXNwb25kZXJzLCB0 byBhbGxvdyB0aGVtIHRvIHJlc2lzdCBEZW5pYWwgb2YgU2VydmljZSBhbmQgRGlzdHJpYnV0 ZWQKICAgRGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNrcy4gIEFkZGl0aW9uYWxseSwgdGhlIGRv Y3VtZW50IGludHJvZHVjZXMgYQogICBuZXcgbWVjaGFuaXNtIGNhbGxlZCAiQ2xpZW50IFB1 enpsZXMiIHRoYXQgaGVscCBhY2NvbXBsaXNoIHRoaXMgdGFzay4KClN0YXR1cyBvZiBUaGlz IE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0 cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDks IDIwMTYuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTYgSUVURiBU cnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0 aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9u cyB3aXRoIHJlc3BlY3QKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2Vw dGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2gg MjAxNgoKCiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVk IGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIAoKCk5pciAmIFNteXNsb3YgJiBC YXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAg ICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25z IGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4g dGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4g IEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICAyCiAgICAgMS4xLiAgVGhlIFN0YXRlbGVzcyBDb29raWUgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDEuMi4gIENvbnZlbnRpb25z IFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAg Mi4gIFRoZSBWdWxuZXJhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0CiAgIDMuICBQdXp6bGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA0LiAgUmV0ZW50aW9uIFBl cmlvZHMgZm9yIEhhbGYtT3BlbiBTQXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgK ICAgNS4gIFJhdGUgTGltaXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA5CiAgIDYuICBQbGFuIGZvciBEZWZlbmRpbmcgYSBSZXNwb25k ZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgIDYuMS4gIFNlc3Np b24gUmVzdW1wdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTMKICAgICA2LjIuICBIQVNIIGFuZCBVUkwgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgIDcuICBVc2luZyBQdXp6bGVzIGluIHRoZSBQcm90 b2NvbCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDcuMS4gIFB1 enpsZXMgaW4gSUtFX1NBX0lOSVQgRXhjaGFuZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTQKICAgICAgIDcuMS4xLiAgUHJlc2VudGluZyBQdXp6bGUgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAgICAgICA3LjEuMi4gIFNvbHZpbmcgUHV6emxl IGFuZCBSZXR1cm5pbmcgdGhlIFNvbHV0aW9uIC4gLiAuIC4gLiAuICAxNwogICAgICAgNy4x LjMuICBDb21wdXRpbmcgUHV6emxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTgKICAgICAgIDcuMS40LiAgQW5hbHl6aW5nIFJlcGVhdGVkIFJlcXVlc3QgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgICAgICA3LjEuNS4gIE1ha2luZyBEZWNp c2lvbiB3aGV0aGVyIHRvIFNlcnZlIHRoZSBSZXF1ZXN0ICAuIC4gLiAuICAyMAogICAgIDcu Mi4gIFB1enpsZXMgaW4gSUtFX0FVVEggRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjEKICAgICAgIDcuMi4xLiAgUHJlc2VudGluZyBQdXp6bGUgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIxCiAgICAgICA3LjIuMi4gIFNvbHZpbmcg UHV6emxlIGFuZCBSZXR1cm5pbmcgdGhlIFNvbHV0aW9uIC4gLiAuIC4gLiAuICAyMgogICAg ICAgNy4yLjMuICBDb21wdXRpbmcgUHV6emxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMjMKICAgICAgIDcuMi40LiAgUmVjZWl2aW5nIFB1enpsZSBTb2x1dGlv biAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIzCiAgIDguICBEb1MgUHJvdGVjdGlv biBhZnRlciBJS0UgU0EgaXMgY3JlYXRlZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyNAog ICA5LiAgUGF5bG9hZCBGb3JtYXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjUKICAgICA5LjEuICBQVVpaTEUgTm90aWZpY2F0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI1CiAgICAgOS4yLiAgUHV6emxl IFNvbHV0aW9uIFBheWxvYWQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAy NgogICAxMC4gT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjYKICAgMTEuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI3CiAgIDEyLiBJQU5BIENv bnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAyOAogICAxMy4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMjgKICAgMTQuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI4CiAgICAgMTQuMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAyOAogICAgIDE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjkKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMwCgogICAgMS4g IEludHJvZHVjdGlvbgoKICAgRGVuaWFsIG9mIFNlcnZpY2UgKERvUykgYXR0YWNrcyBoYXZl IGFsd2F5cyBiZWVuIGNvbnNpZGVyZWQgYSBzZXJpb3VzCiAgIHRocmVhdC4gIFRoZXNlIGF0 dGFja3MgYXJlIHVzdWFsbHkgZGlmZmljdWx0IHRvIGRlZmVuZCBhZ2FpbnN0IHNpbmNlCiAg IHRoZSBhbW91bnQgb2YgcmVzb3VyY2VzIHRoZSB2aWN0aW0gaGFzIGlzIGFsd2F5cyBib3Vu ZGVkIChyZWdhcmRsZXNzCiAgIG9mIGhvdyBoaWdoIGl0IGlzKSBhbmQgYmVjYXVzZSBzb21l IHJlc291cmNlcyBhcmUgcmVxdWlyZWQgZm9yCiAgIGRpc3Rpbmd1aXNoaW5nIGEgbGVnaXRp bWF0ZSBzZXNzaW9uIGZyb20gYW4gYXR0YWNrLgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0 bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAzXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAg ICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIFRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgcHJv dG9jb2wgKElLRSkgZGVzY3JpYmVkIGluIFtSRkM3Mjk2XQogICBpbmNsdWRlcyBkZWZlbnNl IGFnYWluc3QgRG9TIGF0dGFja3MuICBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBpcyBhCiAgIGNv b2tpZSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdGhlIElLRSBSZXNwb25kZXIgdG8gZWZmZWN0 aXZlbHkgZGVmZW5kCiAgIGl0c2VsZiBhZ2FpbnN0IERvUyBhdHRhY2tzIGZyb20gc3Bvb2Zl ZCBJUC1hZGRyZXNzZXMuICBIb3dldmVyLCBib3QtCiAgIG5ldHMgaGF2ZSBiZWNvbWUgd2lk ZXNwcmVhZCwgYWxsb3dpbmcgYXR0YWNrZXJzIHRvIHBlcmZvcm0KICAgRGlzdHJpYnV0ZWQg RGVuaWFsIG9mIFNlcnZpY2UgKEREb1MpIGF0dGFja3MsIHdoaWNoIGFyZSBtb3JlCiAgIGRp ZmZpY3VsdCB0byBkZWZlbmQgYWdhaW5zdC4gIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgcmVj b21tZW5kYXRpb25zCiAgIHRvIGhlbHAgdGhlIFJlc3BvbmRlciB0aHdhcnQgKEQpRG9TIGF0 dGFja3MuICBJdCBhbHNvIGludHJvZHVjZXMgYQogICBuZXcgbWVjaGFuaXNtIC0tICJwdXp6 bGVzIiAtLSB0aGF0IGNhbiBoZWxwIGFjY29tcGxpc2ggdGhpcyB0YXNrLgoKICAgVGhlIElL RV9TQV9JTklUIEV4Y2hhbmdlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEuMiBvZiBbUkZDNzI5 Nl0KICAgaW52b2x2ZXMgdGhlIEluaXRpYXRvciBzZW5kaW5nIGEgc2luZ2xlIG1lc3NhZ2Uu ICBUaGUgUmVzcG9uZGVyCiAgIHJlcGxpZXMgd2l0aCBhIHNpbmdsZSBtZXNzYWdlIGFuZCBh bHNvIGFsbG9jYXRlcyBtZW1vcnkgZm9yIGEKICAgc3RydWN0dXJlIGNhbGxlZCBhIGhhbGYt b3BlbiBJS0UgU2VjdXJpdHkgQXNzb2NpYXRpb24gKFNBKS4gIFRoaXMKICAgaGFsZi1vcGVu IFNBIGlzIGxhdGVyIGF1dGhlbnRpY2F0ZWQgaW4gdGhlIElLRV9BVVRIIEV4Y2hhbmdlLiAg SWYKICAgdGhhdCBJS0VfQVVUSCByZXF1ZXN0IG5ldmVyIGNvbWVzLCB0aGUgaGFsZi1vcGVu IFNBIGlzIGtlcHQgZm9yIGFuCiAgIHVuc3BlY2lmaWVkIGFtb3VudCBvZiB0aW1lLiAgRGVw ZW5kaW5nIG9uIHRoZSBhbGdvcml0aG1zIHVzZWQgYW5kCiAgIGltcGxlbWVudGF0aW9uLCBz dWNoIGEgaGFsZi1vcGVuIFNBIHdpbGwgdXNlIGZyb20gYXJvdW5kIDEwMCBieXRlcyB0bwog ICBzZXZlcmFsIHRob3VzYW5kcyBieXRlcyBvZiBtZW1vcnkuCgogICBUaGlzIGNyZWF0ZXMg YW4gZWFzeSBhdHRhY2sgdmVjdG9yIGFnYWluc3QgYW4gSUtFIFJlc3BvbmRlci4KICAgR2Vu ZXJhdGluZyB0aGUgSUtFX1NBX0lOSVQgcmVxdWVzdCBpcyBjaGVhcCwgYW5kIHNlbmRpbmcg bXVsdGlwbGUKICAgc3VjaCByZXF1ZXN0cyBjYW4gZWl0aGVyIGNhdXNlIHRoZSBSZXNwb25k ZXIgdG8gYWxsb2NhdGUgdG9vIG11Y2gKICAgcmVzb3VyY2VzIGFuZCBmYWlsLCBvciBlbHNl IGlmIHJlc291cmNlIGFsbG9jYXRpb24gaXMgc29tZWhvdwogICB0aHJvdHRsZWQsIGxlZ2l0 aW1hdGUgSW5pdGlhdG9ycyB3b3VsZCBhbHNvIGJlIHByZXZlbnRlZCBmcm9tIHNldHRpbmcK ICAgdXAgSUtFIFNBcy4KCiAgIEFuIG9idmlvdXMgZGVmZW5zZSwgd2hpY2ggaXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNSwgaXMgbGltaXRpbmcgdGhlCiAgIG51bWJlciBvZiBoYWxmLW9w ZW4gU0FzIG9wZW5lZCBieSBhIHNpbmdsZSBwZWVyLiAgSG93ZXZlciwgc2luY2UgYWxsCiAg IHRoYXQgaXMgcmVxdWlyZWQgaXMgYSBzaW5nbGUgcGFja2V0LCBhbiBhdHRhY2tlciBjYW4g dXNlIG11bHRpcGxlCiAgIHNwb29mZWQgc291cmNlIElQIGFkZHJlc3Nlcy4KCiAgICAgIDEu MS4gIFRoZSBTdGF0ZWxlc3MgQ29va2llCgogICBTZWN0aW9uIDIuNiBvZiBbUkZDNzI5Nl0g b2ZmZXJzIGEgbWVjaGFuaXNtIHRvIG1pdGlnYXRlIHRoaXMgRG9TCiAgIGF0dGFjazogdGhl IHN0YXRlbGVzcyBjb29raWUuICBXaGVuIHRoZSBzZXJ2ZXIgaXMgdW5kZXIgbG9hZCwgdGhl CiAgIFJlc3BvbmRlciByZXNwb25kcyB0byB0aGUgSUtFX1NBX0lOSVQgcmVxdWVzdCB3aXRo IGEgY2FsY3VsYXRlZAogICAic3RhdGVsZXNzIGNvb2tpZSIgLSBhIHZhbHVlIHRoYXQgY2Fu IGJlIHJlLWNhbGN1bGF0ZWQgYmFzZWQgb24KICAgdmFsdWVzIGluIHRoZSBJS0VfU0FfSU5J VCByZXF1ZXN0IHdpdGhvdXQgc3RvcmluZyBSZXNwb25kZXItc2lkZQogICBzdGF0ZS4gIFRo ZSBJbml0aWF0b3IgaXMgZXhwZWN0ZWQgdG8gcmVwZWF0IHRoZSBJS0VfU0FfSU5JVCByZXF1 ZXN0LAogICB0aGlzIHRpbWUgaW5jbHVkaW5nIHRoZSBzdGF0ZWxlc3MgY29va2llLgoKICAg QXR0YWNrZXJzIHRoYXQgaGF2ZSBtdWx0aXBsZSBzb3VyY2UgSVAgYWRkcmVzc2VzIHdpdGgg cmV0dXJuCiAgIHJvdXRhYmlsaXR5LCBzdWNoIGFzIGluIHRoZSBjYXNlIG9mIGJvdC1uZXRz LCBjYW4gZmlsbCB1cCBhIGhhbGYtb3BlbgogICBTQSB0YWJsZSBhbnl3YXkuICBUaGUgY29v a2llIG1lY2hhbmlzbSBsaW1pdHMgdGhlIGFtb3VudCBvZiBhbGxvY2F0ZWQKICAgc3RhdGUg dG8gdGhlIHNpemUgb2YgdGhlIGJvdC1uZXQsIG11bHRpcGxpZWQgYnkgdGhlIG51bWJlciBv ZiBoYWxmLQogICBvcGVuIFNBcyBhbGxvd2VkIHBlciBwZWVyIGFkZHJlc3MsIG11bHRpcGxp ZWQgYnkgdGhlIGFtb3VudCBvZiBzdGF0ZQoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0 dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSA0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAg ICAgICAgTWFyY2ggMjAxNgoKCiAgIGFsbG9jYXRlZCBmb3IgZWFjaCBoYWxmLW9wZW4gU0Eu ICBXaXRoIHR5cGljYWwgdmFsdWVzIHRoaXMgY2FuIGVhc2lseQogICByZWFjaCBodW5kcmVk cyBvZiBtZWdhYnl0ZXMuCgogICBUaGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDMgYWRkcyBhIHByb29mIG9mIHdvcmsgZm9yIHRoZQogICBJbml0aWF0b3IgYnkgY2FsY3Vs YXRpbmcgYSBwcmUtaW1hZ2UgZm9yIGEgcGFydGlhbCBoYXNoIHZhbHVlLiAgVGhpcwogICBz ZXRzIGFuIHVwcGVyIGJvdW5kLCBkZXRlcm1pbmVkIGJ5IHRoZSBhdHRhY2tlcidzIENQVSwg dG8gdGhlIG51bWJlcgogICBvZiBuZWdvdGlhdGlvbnMgaXQgY2FuIGluaXRpYXRlIGluIGEg dW5pdCBvZiB0aW1lLgoKICAgICAgMS4yLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERv Y3VtZW50CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAg IDIuICBUaGUgVnVsbmVyYWJpbGl0eQoKICAgSWYgd2UgYnJlYWsgZG93biB3aGF0IGEgUmVz cG9uZGVyIGhhcyB0byBkbyBkdXJpbmcgYW4gaW5pdGlhbAogICBleGNoYW5nZSwgdGhlcmUg YXJlIHRocmVlIHN0YWdlczoKCiAgICAgICAxLiAgV2hlbiB0aGUgSUtFX1NBX0lOSVQgcmVx dWVzdCBhcnJpdmVzLCB0aGUgUmVzcG9uZGVyOgoKICAgICAgICAgICogIEdlbmVyYXRlcyBv ciByZS11c2VzIGEgRGlmZmllLUhlbGxtYW4gKEQtSCkgcHJpdmF0ZSBwYXJ0LgoKICAgICAg ICAgICogIEdlbmVyYXRlcyBhIFJlc3BvbmRlciBTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXgg KFNQSSkuCgogICAgICAgICAgKiAgU3RvcmVzIHRoZSBwcml2YXRlIHBhcnQgYW5kIHBlZXIg cHVibGljIHBhcnQgaW4gYSBoYWxmLW9wZW4KICAgICAgICAgIFNBIGRhdGFiYXNlLgoKICAg ICAgIDIuICBXaGVuIHRoZSBJS0VfQVVUSCByZXF1ZXN0IGFycml2ZXMsIHRoZSBSZXNwb25k ZXI6CgogICAgICAgICAgKiAgRGVyaXZlcyB0aGUga2V5cyBmcm9tIHRoZSBoYWxmLW9wZW4g U0EuCgogICAgICAgICAgKiAgRGVjcnlwdHMgdGhlIHJlcXVlc3QuCgogICAgICAgMy4gIElm IHRoZSBJS0VfQVVUSCByZXF1ZXN0IGRlY3J5cHRzIHByb3Blcmx5OgoKICAgICAgICAgICog IFZhbGlkYXRlcyB0aGUgY2VydGlmaWNhdGUgY2hhaW4gKGlmIHByZXNlbnQpIGluIHRoZQog ICAgICAgICAgSUtFX0FVVEggcmVxdWVzdC4KCiAgIFllcywgdGhlcmUncyBhIHN0YWdlIDQg d2hlcmUgdGhlIFJlc3BvbmRlciBhY3R1YWxseSBjcmVhdGVzIENoaWxkCiAgIFNBcywgYnV0 IHdoZW4gdGFsa2luZyBhYm91dCAoRClEb1MsIHdlIG5ldmVyIGdldCB0byB0aGlzIHN0YWdl LgoKICAgU3RhZ2UgIzEgaXMgcHJldHR5IGxpZ2h0IG9uIENQVSBwb3dlciwgYnV0IHJlcXVp cmVzIHNvbWUgc3RvcmFnZSwgYW5kCiAgIGl0J3MgdmVyeSBsaWdodCBmb3IgdGhlIEluaXRp YXRvciBhcyB3ZWxsLiAgU3RhZ2UgIzIgaW5jbHVkZXMKICAgcHJpdmF0ZS1rZXkgb3BlcmF0 aW9ucywgc28gaXQncyBtdWNoIGhlYXZpZXIgQ1BVLXdpc2UuICBTdGFnZSAjMwogICBpbmNs dWRlcyBwdWJsaWMga2V5IG9wZXJhdGlvbnMsIHR5cGljYWxseSBtb3JlIHRoYW4gb25lLgoK CiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2 ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1Mg UHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBUbyBh dHRhY2sgc3VjaCBhIFJlc3BvbmRlciwgYW4gYXR0YWNrZXIgY2FuIGF0dGVtcHQgdG8gZWl0 aGVyIGV4aGF1c3QKICAgbWVtb3J5IG9yIHRvIGV4aGF1c3QgQ1BVLiAgV2l0aG91dCBhbnkg cHJvdGVjdGlvbiwgdGhlIG1vc3QgZWZmaWNpZW50CiAgIGF0dGFjayBpcyB0byBzZW5kIG11 bHRpcGxlIElLRV9TQV9JTklUIHJlcXVlc3RzIGFuZCBleGhhdXN0IG1lbW9yeS4KICAgVGhp cyBzaG91bGQgYmUgZWFzeSBiZWNhdXNlIHRob3NlIHJlcXVlc3RzIGFyZSBjaGVhcC4KCiAg IFRoZXJlIGFyZSBvYnZpb3VzIHdheXMgZm9yIHRoZSBSZXNwb25kZXIgdG8gcHJvdGVjdCBp dHNlbGYgZXZlbgogICB3aXRob3V0IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiAgSXQgY2Fu IHJlZHVjZSB0aGUgdGltZSB0aGF0IGFuCiAgIGVudHJ5IHJlbWFpbnMgaW4gdGhlIGhhbGYt b3BlbiBTQSBkYXRhYmFzZSwgYW5kIGl0IGNhbiBsaW1pdCB0aGUKICAgYW1vdW50IG9mIGNv bmN1cnJlbnQgaGFsZi1vcGVuIFNBcyBmcm9tIGEgcGFydGljdWxhciBhZGRyZXNzIG9yCiAg IHByZWZpeC4gIFRoZSBhdHRhY2tlciBjYW4gb3ZlcmNvbWUgdGhpcyBieSB1c2luZyBzcG9v ZmVkIHNvdXJjZQogICBhZGRyZXNzZXMuCgogICBUaGUgc3RhdGVsZXNzIGNvb2tpZSBtZWNo YW5pc20gZnJvbSBTZWN0aW9uIDIuNiBvZiBbUkZDNzI5Nl0gcHJldmVudHMKICAgYW4gYXR0 YWNrIHdpdGggc3Bvb2ZlZCBzb3VyY2UgYWRkcmVzc2VzLiAgVGhpcyBkb2Vzbid0IGNvbXBs ZXRlbHkKICAgc29sdmUgdGhlIGlzc3VlLCBidXQgaXQgbWFrZXMgdGhlIGxpbWl0aW5nIG9m IGhhbGYtb3BlbiBTQXMgYnkKICAgYWRkcmVzcyBvciBwcmVmaXggd29yay4gIFB1enpsZXMg ZG8gdGhlIHNhbWUgdGhpbmcgb25seSBtb3JlIG9mIGl0LgogICBUaGV5IG1ha2UgaXQgaGFy ZGVyIGZvciBhbiBhdHRhY2tlciB0byByZWFjaCB0aGUgZ29hbCBvZiBnZXR0aW5nIGEKICAg aGFsZi1vcGVuIFNBLiAgVGhleSBkb24ndCBoYXZlIHRvIGJlIHNvIGhhcmQgdGhhdCBhbiBh dHRhY2tlciBjYW4ndAogICBhZmZvcmQgdG8gc29sdmUgYSBzaW5nbGUgcHV6emxlOyBpdCdz IGVub3VnaCB0aGF0IHRoZXkgaW5jcmVhc2UgdGhlCiAgIGNvc3Qgb2YgYSBoYWxmLW9wZW4g U0FzIGZvciB0aGUgYXR0YWNrZXIgc28gdGhhdCBpdCBjYW4gY3JlYXRlIG9ubHkgYQogICBm ZXcuCgogICBSZWR1Y2luZyB0aGUgYW1vdW50IG9mIHRpbWUgYW4gYWJhbmRvbmVkIGhhbGYt b3BlbiBTQSBpcyBrZXB0IGF0dGFja3MKICAgdGhlIGlzc3VlIGZyb20gdGhlIG90aGVyIHNp ZGUuICBJdCByZWR1Y2VzIHRoZSB2YWx1ZSB0aGUgYXR0YWNrZXIKICAgZ2V0cyBmcm9tIG1h bmFnaW5nIHRvIGNyZWF0ZSBhIGhhbGYtb3BlbiBTQS4gIEZvciBleGFtcGxlLCBpZiBhIGhh bGYtCiAgIG9wZW4gU0EgaXMga2VwdCBmb3IgMSBtaW51dGUgYW5kIHRoZSBjYXBhY2l0eSBp cyA2MCwwMDAgaGFsZi1vcGVuCiAgIFNBcywgYW4gYXR0YWNrZXIgd291bGQgbmVlZCB0byBj cmVhdGUgMSwwMDAgaGFsZi1vcGVuIFNBcyBwZXIgc2Vjb25kLgogICBSZWR1Y2UgdGhlIHJl dGVudGlvbiB0aW1lIHRvIDMgc2Vjb25kcywgYW5kIHRoZSBhdHRhY2tlciBuZWVkcyB0bwog ICBjcmVhdGUgMjAsMDAwIGhhbGYtb3BlbiBTQXMgcGVyIHNlY29uZC4gIEJ5IGludHJvZHVj aW5nIGEgcHV6emxlLAogICBlYWNoIGhhbGYtb3BlbiBTQSBiZWNvbWVzIG1vcmUgZXhwZW5z aXZlIGZvciBhbiBhdHRhY2tlciwgbWFraW5nIGl0CiAgIG1vcmUgbGlrZWx5IHRvIHRod2Fy dCBhbiBleGhhdXN0aW9uIGF0dGFjayBhZ2FpbnN0IFJlc3BvbmRlciBtZW1vcnkuCgogICBB dCB0aGlzIHBvaW50LCBmaWxsaW5nIHVwIHRoZSBoYWxmLW9wZW4gU0EgZGF0YWJhc2UgaXMg bm8gbG9uZ2VyIHRoZQogICBtb3N0IGVmZmljaWVudCBEb1MgYXR0YWNrLiAgVGhlIGF0dGFj a2VyIGhhcyB0d28gd2F5cyB0byBkbyBiZXR0ZXI6CgogICAgICAgMS4gIEdvIGJhY2sgdG8g c3Bvb2ZlZCBhZGRyZXNzZXMgYW5kIHRyeSB0byBvdmVyd2hlbG0gdGhlIENQVQogICAgICAg dGhhdCBkZWFscyB3aXRoIGdlbmVyYXRpbmcgY29va2llcywgb3IKCiAgICAgICAyLiAgVGFr ZSB0aGUgYXR0YWNrIHRvIHRoZSBuZXh0IGxldmVsIGJ5IGFsc28gc2VuZGluZyBhbiBJS0Vf QVVUSAogICAgICAgcmVxdWVzdC4KCiAgIEl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0IHRoaW5n IGNhbm5vdCBiZSBkZWFsdCB3aXRoIGF0IHRoZSBJS0UgbGV2ZWwuCiAgIEl0J3MgcHJvYmFi bHkgYmV0dGVyIGxlZnQgdG8gSW50cnVzaW9uIFByZXZlbnRpb24gU3lzdGVtIChJUFMpCiAg IHRlY2hub2xvZ3kuCgogICBPbiB0aGUgb3RoZXIgaGFuZCwgc2VuZGluZyBhbiBJS0VfQVVU SCByZXF1ZXN0IGlzIHN1cnByaXNpbmdseSBjaGVhcC4KICAgSXQgcmVxdWlyZXMgYSBwcm9w ZXIgSUtFIGhlYWRlciB3aXRoIHRoZSBjb3JyZWN0IElLRSBTUElzLCBhbmQgaXQKICAgcmVx dWlyZXMgYSBzaW5nbGUgRW5jcnlwdGVkIHBheWxvYWQuICBUaGUgY29udGVudCBvZiB0aGUg cGF5bG9hZAogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIg OSwgMjAxNiAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoK ICAgbWlnaHQgYXMgd2VsbCBiZSBqdW5rLiAgVGhlIFJlc3BvbmRlciBoYXMgdG8gcGVyZm9y bSB0aGUgcmVsYXRpdmVseQogICBleHBlbnNpdmUga2V5IGRlcml2YXRpb24sIG9ubHkgdG8g ZmluZCB0aGF0IHRoZSBNQUMgb24gdGhlIEVuY3J5cHRlZAogICBwYXlsb2FkIG9uIHRoZSBJ S0VfQVVUSCByZXF1ZXN0IGRvZXMgbm90IGNoZWNrLiAgRGVwZW5kaW5nIG9uIHRoZQogICBS ZXNwb25kZXIgaW1wbGVtZW50YXRpb24sIHRoaXMgY2FuIGJlIHJlcGVhdGVkIHdpdGggdGhl IHNhbWUgaGFsZi0KICAgb3BlbiBTQSAoaWYgdGhlIFJlc3BvbmRlciBkb2VzIG5vdCBkZWxl dGUgdGhlIGhhbGYtb3BlbiBTQSBmb2xsb3dpbmcKICAgYW4gdW5zdWNjZXNzZnVsIGRlY3J5 cHRpb24gLSBzZWUgZGlzY3Vzc2lvbiBpbiBTZWN0aW9uIDQpLgoKICAgSGVyZSB0b28sIHRo ZSBudW1iZXIgb2YgaGFsZi1vcGVuIFNBcyB0aGF0IHRoZSBhdHRhY2tlciBjYW4gYWNoaWV2 ZQogICBpcyBjcnVjaWFsLCBiZWNhdXNlIGVhY2ggb25lIGFsbG93cyB0aGUgYXR0YWNrZXIg dG8gd2FzdGUgc29tZSBDUFUKICAgdGltZS4gIFNvIG1ha2luZyBpdCBoYXJkIHRvIG1ha2Ug bWFueSBoYWxmLW9wZW4gU0FzIGlzIGltcG9ydGFudC4KCiAgIEEgc3RyYXRlZ3kgYWdhaW5z dCBERG9TIGhhcyB0byByZWx5IG9uIGF0IGxlYXN0IDQgY29tcG9uZW50czoKCiAgICAgICAx LiAgSGFyZGVuaW5nIHRoZSBoYWxmLW9wZW4gU0EgZGF0YWJhc2UgYnkgcmVkdWNpbmcgcmV0 ZW50aW9uCiAgICAgICB0aW1lLgoKICAgICAgIDIuICBIYXJkZW5pbmcgdGhlIGhhbGYtb3Bl biBTQSBkYXRhYmFzZSBieSByYXRlLWxpbWl0aW5nIHNpbmdsZQogICAgICAgSVBzLyBwcmVm aXhlcy4KCiAgICAgICAzLiAgR3VpZGFuY2Ugb24gd2hhdCB0byBkbyB3aGVuIGFuIElLRV9B VVRIIHJlcXVlc3QgZmFpbHMgdG8KICAgICAgIGRlY3J5cHQuCgogICAgICAgNC4gIEluY3Jl YXNpbmcgY29zdCBvZiBoYWxmLW9wZW4gU0EgdXAgdG8gd2hhdCBpcyB0b2xlcmFibGUgZm9y CiAgICAgICBsZWdpdGltYXRlIGNsaWVudHMuCgogICBQdXp6bGVzIGhhdmUgdGhlaXIgcGxh Y2UgYXMgcGFydCBvZiAjNC4KCiAgICAzLiAgUHV6emxlcwoKICAgVGhlIHB1enpsZSBpbnRy b2R1Y2VkIGhlcmUgZXh0ZW5kcyB0aGUgY29va2llIG1lY2hhbmlzbSBmcm9tCiAgIFtSRkM3 Mjk2XS4gIEl0IGlzIGxvb3NlbHkgYmFzZWQgb24gdGhlIHByb29mLW9mLXdvcmsgdGVjaG5p cXVlIHVzZWQKICAgaW4gQml0Y29pbnMgW2JpdGNvaW5zXS4KCiAgIEEgcHV6emxlIGlzIHNl bnQgdG8gdGhlIEluaXRpYXRvciBpbiB0d28gY2FzZXM6CgogICAgICBvICBUaGUgUmVzcG9u ZGVyIGlzIHNvIG92ZXJsb2FkZWQgdGhhdCBubyBoYWxmLW9wZW4gU0FzIG1heSBiZQogICAg ICBjcmVhdGVkIHdpdGhvdXQgc29sdmluZyBhIHB1enpsZSwgb3IKCiAgICAgIG8gIFRoZSBS ZXNwb25kZXIgaXMgbm90IHRvbyBsb2FkZWQsIGJ1dCB0aGUgcmF0ZS1saW1pdGluZyBtZXRo b2QKICAgICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNSBwcmV2ZW50cyBoYWxmLW9wZW4gU0Fz IGZyb20gYmVpbmcgY3JlYXRlZAogICAgICB3aXRoIHRoaXMgcGFydGljdWxhciBwZWVyIGFk ZHJlc3Mgb3IgcHJlZml4IHdpdGhvdXQgZmlyc3Qgc29sdmluZwogICAgICBhIHB1enpsZS4K CiAgIFdoZW4gdGhlIFJlc3BvbmRlciBkZWNpZGVzIHRvIHNlbmQgdGhlIGNoYWxsZW5nZSBu b3RpZmljYXRpb24gaW4KICAgcmVzcG9uc2UgdG8gYSBJS0VfU0FfSU5JVCByZXF1ZXN0LCB0 aGUgbm90aWZpY2F0aW9uIGluY2x1ZGVzIHRocmVlCiAgIGZpZWxkczoKCiAgICAgICAxLiAg Q29va2llIC0gdGhpcyBpcyBjYWxjdWxhdGVkIHRoZSBzYW1lIGFzIGluIFtSRkM3Mjk2XSwg aS5lLgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwg MjAxNiAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBE RG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAg ICAgIHRoZSBwcm9jZXNzIG9mIGdlbmVyYXRpbmcgdGhlIGNvb2tpZSBpcyBub3Qgc3BlY2lm aWVkLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAK CgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAg ICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJv dGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICAyLiAgQWxn b3JpdGhtLCB0aGlzIGlzIHRoZSBpZGVudGlmaWVyIG9mIGEgUHNldWRvLVJhbmRvbSBGdW5j dGlvbgogICAgICAgKFBSRikgYWxnb3JpdGhtLCBvbmUgb2YgdGhvc2UgcHJvcG9zZWQgYnkg dGhlIEluaXRpYXRvciBpbiB0aGUgU0EKICAgICAgIHBheWxvYWQuCgogICAgICAgMy4gIFpl cm8gQml0IENvdW50IChaQkMpLiAgVGhpcyBpcyBhIG51bWJlciBiZXR3ZWVuIDggYW5kIDI1 NSAob3IKICAgICAgIGEgc3BlY2lhbCB2YWx1ZSAtIDAsIHNlZSBTZWN0aW9uIDcuMS4xLjEp IHRoYXQgcmVwcmVzZW50cyB0aGUKICAgICAgIGxlbmd0aCBvZiB0aGUgemVyby1iaXQgcnVu IGF0IHRoZSBlbmQgb2YgdGhlIG91dHB1dCBvZiB0aGUgUFJGCiAgICAgICBmdW5jdGlvbiBj YWxjdWxhdGVkIG92ZXIgdGhlIGNvb2tpZSB0aGF0IHRoZSBJbml0aWF0b3IgaXMgdG8KICAg ICAgIHNlbmQuICBUaGUgdmFsdWVzIDEtOCBhcmUgZXhwbGljaXRseSBleGNsdWRlZCwgYmVj YXVzZSB0aGV5CiAgICAgICBjcmVhdGUgYSBwdXp6bGUgdGhhdCBpcyB0b28gZWFzeSB0byBz b2x2ZSBmb3IgaXQgdG8gbWFrZSBhbnkKICAgICAgIGRpZmZlcmVuY2UgaW4gbWl0aWdhdGlu ZyBERG9TIGF0dGFja3MuICBTaW5jZSB0aGUgbWVjaGFuaXNtIGlzCiAgICAgICBzdXBwb3Nl ZCB0byBiZSBzdGF0ZWxlc3MgZm9yIHRoZSBSZXNwb25kZXIsIGVpdGhlciB0aGUgc2FtZSBa QkMKICAgICAgIGlzIHVzZWQgZm9yIGFsbCBJbml0aWF0b3JzLCBvciB0aGUgWkJDIGlzIHNv bWVob3cgZW5jb2RlZCBpbiB0aGUKICAgICAgIGNvb2tpZS4gIElmIGl0IGlzIGdsb2JhbCB0 aGVuIGl0IG1lYW5zIHRoYXQgdGhpcyB2YWx1ZSBpcyB0aGUKICAgICAgIHNhbWUgZm9yIGFs bCB0aGUgSW5pdGlhdG9ycyB3aG8gYXJlIHJlY2VpdmluZyBwdXp6bGVzIGF0IGFueQogICAg ICAgZ2l2ZW4gcG9pbnQgb2YgdGltZS4gIFRoZSBSZXNwb25kZXIsIGhvd2V2ZXIsIG1heSBj aGFuZ2UgdGhpcwogICAgICAgdmFsdWUgb3ZlciB0aW1lIGRlcGVuZGluZyBvbiBpdHMgbG9h ZC4KCiAgIFVwb24gcmVjZWl2aW5nIHRoaXMgY2hhbGxlbmdlLCB0aGUgSW5pdGlhdG9yIGF0 dGVtcHRzIHRvIGNhbGN1bGF0ZQogICB0aGUgUFJGIHVzaW5nIGRpZmZlcmVudCBrZXlzLiAg V2hlbiBlbm91Z2gga2V5cyBhcmUgZm91bmQgc3VjaCB0aGF0CiAgIHRoZSByZXN1bHRpbmcg UFJGIG91dHB1dCBjYWxjdWxhdGVkIHVzaW5nIGVhY2ggb2YgdGhlbSBoYXMgYQogICBzdWZm aWNpZW50IG51bWJlciBvZiB0cmFpbGluZyB6ZXJvIGJpdHMsIHRoYXQgcmVzdWx0IGlzIHNl bnQgdG8gdGhlCiAgIFJlc3BvbmRlci4KCiAgIFRoZSByZWFzb24gZm9yIHVzaW5nIHNldmVy YWwga2V5cyBpbiB0aGUgcmVzdWx0cyByYXRoZXIgdGhhbiBqdXN0IG9uZQogICBrZXkgaXMg dG8gcmVkdWNlIHRoZSB2YXJpYW5jZSBpbiB0aGUgdGltZSBpdCB0YWtlcyB0aGUgaW5pdGlh dG9yIHRvCiAgIHNvbHZlIHRoZSBwdXp6bGUuICBXZSBoYXZlIGNob3NlbiB0aGUgbnVtYmVy IG9mIGtleXMgdG8gYmUgZm91ciAoNCkKICAgYXMgYSBjb21wcm9taXNlIGJldHdlZW4gdGhl IGNvbmZsaWN0aW5nIGdvYWxzIG9mIHJlZHVjaW5nIHZhcmlhbmNlCiAgIGFuZCByZWR1Y2lu ZyB0aGUgd29yayB0aGUgUmVzcG9uZGVyIG5lZWRzIHRvIHBlcmZvcm0gdG8gdmVyaWZ5IHRo ZQogICBwdXp6bGUgc29sdXRpb24uCgogICBXaGVuIHJlY2VpdmluZyBhIHJlcXVlc3Qgd2l0 aCBhIHNvbHZlZCBwdXp6bGUsIHRoZSBSZXNwb25kZXIgdmVyaWZpZXMKICAgdHdvIHRoaW5n czoKCiAgICAgIG8gIFRoYXQgdGhlIGNvb2tpZSBwYXJ0IGlzIGluZGVlZCB2YWxpZC4KCiAg ICAgIG8gIFRoYXQgdGhlIFBSRnMgb2YgdGhlIHRyYW5zbWl0dGVkIGNvb2tpZSBjYWxjdWxh dGVkIHdpdGggdGhlCiAgICAgIHRyYW5zbWl0dGVkIGtleXMgaGFzIGEgc3VmZmljaWVudCBu dW1iZXIgb2YgdHJhaWxpbmcgemVybyBiaXRzLgoKICAgRXhhbXBsZSAxOiBTdXBwb3NlIHRo ZSBjYWxjdWxhdGVkIGNvb2tpZSBpcwogICA3MzlhZTc0OTJkOGE4MTBjZjVlOGRjMGY5NjI2 YzlkZGE3NzNjNWEzICgyMCBvY3RldHMpLCB0aGUgYWxnb3JpdGhtCiAgIGlzIFBSRi1ITUFD LVNIQTI1NiwgYW5kIHRoZSByZXF1aXJlZCBudW1iZXIgb2YgemVybyBiaXRzIGlzIDE4LiBB ZnRlcgogICBzdWNjZXNzaXZlbHkgdHJ5aW5nIGEgYnVuY2ggb2Yga2V5cywgdGhlIEluaXRp YXRvciBmaW5kcyB0aGUKICAgZm9sbG93aW5nIGZvdXIgMy1vY3RldCBrZXlzIHRoYXQgd29y azoKCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5 LCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgog ICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tKwogICAgICAgICB8ICBLZXkgICB8IExhc3QgMzIgSGV4IFBSRiBEaWdpdHMg ICAgICAgICAgIHwgIyAwLWJpdHMgfAogICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICB8IDA2MTg0MCB8 IGU0Zjk1N2I4NTlkN2ZiMTM0M2I3Yjk0YTgxNmMwMDAwIHwgICAgMTggICAgfAogICAgICAg ICB8IDA3MzMyNCB8IDBkNDIzM2Q2Mjc4Yzk2ZTMzNjkyMjdhMDc1ODAwMDAwIHwgICAgMjMg ICAgfAogICAgICAgICB8IDBjOGEyYSB8IDk1MmEzNWQzOWQ1YmEwNjcwOWRhNDNhZjQwNzAw MDAwIHwgICAgMjAgICAgfAogICAgICAgICB8IDBkOTRjOCB8IDVhMDQ1MmIyMTU3MWU0MDFh M2QwMDgwMzY3OWMwMDAwIHwgICAgMTggICAgfAogICAgICAgICArLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgVGFibGUgMTogVGhyZWUgc29sdXRpb25zIGZv ciAxOC1iaXQgcHV6emxlCgogICBFeGFtcGxlIDI6IFNhbWUgY29va2llLCBidXQgbW9kaWZ5 IHRoZSByZXF1aXJlZCBudW1iZXIgb2YgemVybyBiaXRzCiAgIHRvIDIyLiAgVGhlIGZpcnN0 IDQtb2N0ZXQga2V5cyB0aGF0IHdvcmsgdG8gc2F0aXNmeSB0aGF0IHJlcXVpcmVtZW50CiAg IGFyZSAwMDVkOWU1NywgMDEwZDg5NTksIDAxMTA3NzhkLCBhbmQgMDExODdlMzcuICBGaW5k aW5nIHRoZXNlCiAgIHJlcXVpcmVzIDE4LDM4MiwzOTIgaW52b2NhdGlvbnMgb2YgdGhlIFBS Ri4KCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgIHwgIyAwLWJpdHMgfCBUaW1lIHRvIEZpbmQgNCBr ZXlzIChzZWNvbmRzKSB8CiAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgIHwgICAgOCAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIDAuMDAyNSB8CiAgICAgICAgICAgICAgIHwgICAgMTAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIDAuMDA3OCB8CiAgICAgICAgICAgICAgIHwgICAg MTIgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDAuMDUzMCB8CiAgICAgICAgICAgICAg IHwgICAgMTQgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDAuMjUyMSB8CiAgICAgICAg ICAgICAgIHwgICAgMTYgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDAuODUwNCB8CiAg ICAgICAgICAgICAgIHwgICAgMTcgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDEuNTkz OCB8CiAgICAgICAgICAgICAgIHwgICAgMTggICAgfCAgICAgICAgICAgICAgICAgICAgICAg IDMuMzg0MiB8CiAgICAgICAgICAgICAgIHwgICAgMTkgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIDMuODU5MiB8CiAgICAgICAgICAgICAgIHwgICAgMjAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgMTAuODg3NiB8CiAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogIFRhYmxlIDI6IFRoZSB0aW1lIG5lZWRlZCB0byBzb2x2ZSBhIHB1enps ZSBvZiB2YXJpb3VzIGRpZmZpY3VsdHkgZm9yCiAgIHRoZSBjb29raWUgPSA3MzlhZTc0OTJk OGE4MTBjZjVlOGRjMGY5NjI2YzlkZGE3NzNjNWEzCgogICBUaGUgZmlndXJlcyBhYm92ZSB3 ZXJlIG9idGFpbmVkIG9uIGEgMi40IEdIeiBzaW5nbGUgY29yZSBpNS4gIFJ1bgogICB0aW1l cyBjYW4gYmUgaGFsdmVkIG9yIHF1YXJ0ZXJlZCB3aXRoIG11bHRpLWNvcmUgY29kZSwgYnV0 IHdvdWxkIGJlCiAgIGxvbmdlciBvbiBtb2JpbGUgcGhvbmUgcHJvY2Vzc29ycywgZXZlbiBp ZiB0aG9zZSBhcmUgbXVsdGktY29yZSBhcwogICB3ZWxsLiAgV2l0aCB0aGVzZSBmaWd1cmVz IDE4IGJpdHMgaXMgYmVsaWV2ZWQgdG8gYmUgYSByZWFzb25hYmxlCiAgIGNob2ljZSBmb3Ig cHV6emxlIGxldmVsIGRpZmZpY3VsdHkgZm9yIGFsbCBJbml0aWF0b3JzLCBhbmQgMjAgYml0 cyBpcwogICBhY2NlcHRhYmxlIGZvciBzcGVjaWZpYyBob3N0cy9wcmVmaXhlcy4KCiAgICA0 LiAgUmV0ZW50aW9uIFBlcmlvZHMgZm9yIEhhbGYtT3BlbiBTQXMKCiAgIEFzIGEgVURQLWJh c2VkIHByb3RvY29sLCBJS0V2MiBoYXMgdG8gZGVhbCB3aXRoIHBhY2tldCBsb3NzIHRocm91 Z2gKICAgcmV0cmFuc21pc3Npb25zLiAgU2VjdGlvbiAyLjQgb2YgW1JGQzcyOTZdIHJlY29t bWVuZHMgInRoYXQgbWVzc2FnZXMKICAgYmUgcmV0cmFuc21pdHRlZCBhdCBsZWFzdCBhIGRv emVuIHRpbWVzIG92ZXIgYSBwZXJpb2Qgb2YgYXQgbGVhc3QKICAgc2V2ZXJhbCBtaW51dGVz IGJlZm9yZSBnaXZpbmcgdXAiLiAgUmV0cmFuc21pc3Npb24gcG9saWNpZXMgaW4KICAgcHJh Y3RpY2Ugd2FpdCBhdCBsZWFzdCBvbmUgb3IgdHdvIHNlY29uZHMgYmVmb3JlIHJldHJhbnNt aXR0aW5nIGZvcgogICB0aGUgZmlyc3QgdGltZS4KIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0 bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDEwXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAg ICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIEJlY2F1c2Ugb2YgdGhpcywgc2V0dGluZyB0aGUg dGltZW91dCBvbiBhIGhhbGYtb3BlbiBTQSB0b28gbG93IHdpbGwKICAgY2F1c2UgaXQgdG8g ZXhwaXJlIHdoZW5ldmVyIGV2ZW4gb25lIElLRV9BVVRIIHJlcXVlc3QgcGFja2V0IGlzIGxv c3QuCiAgIFdoZW4gbm90IHVuZGVyIGF0dGFjaywgdGhlIGhhbGYtb3BlbiBTQSB0aW1lb3V0 IFNIT1VMRCBiZSBzZXQgaGlnaAogICBlbm91Z2ggdGhhdCB0aGUgSW5pdGlhdG9yIHdpbGwg aGF2ZSBlbm91Z2ggdGltZSB0byBzZW5kIG11bHRpcGxlCiAgIHJldHJhbnNtaXNzaW9ucywg bWluaW1pemluZyB0aGUgY2hhbmNlIG9mIHRyYW5zaWVudCBuZXR3b3JrCiAgIGNvbmdlc3Rp b24gY2F1c2luZyBJS0UgZmFpbHVyZS4KCiAgIFdoZW4gdGhlIHN5c3RlbSBpcyB1bmRlciBh dHRhY2ssIGFzIG1lYXN1cmVkIGJ5IHRoZSBhbW91bnQgb2YgaGFsZi0KICAgb3BlbiBTQXMs IGl0IG1ha2VzIHNlbnNlIHRvIHJlZHVjZSB0aGlzIGxpZmV0aW1lLiAgVGhlIFJlc3BvbmRl cgogICBzaG91bGQgc3RpbGwgYWxsb3cgZW5vdWdoIHRpbWUgZm9yIHRoZSByb3VuZC10cmlw LCBlbm91Z2ggdGltZSBmb3IKICAgdGhlIEluaXRpYXRvciB0byBkZXJpdmUgdGhlIEQtSCBz aGFyZWQgdmFsdWUsIGFuZCBlbm91Z2ggdGltZSB0bwogICBkZXJpdmUgdGhlIElLRSBTQSBr ZXlzIGFuZCB0aGUgY3JlYXRlIHRoZSBJS0VfQVVUSCByZXF1ZXN0LiAgVHdvCiAgIHNlY29u ZHMgaXMgcHJvYmFibHkgYXMgbG93IGEgdmFsdWUgYXMgY2FuIHJlYWxpc3RpY2FsbHkgYmUg dXNlZC4KCiAgIEl0IGNvdWxkIG1ha2Ugc2Vuc2UgdG8gYXNzaWduIGEgc2hvcnRlciB2YWx1 ZSB0byBoYWxmLW9wZW4gU0FzCiAgIG9yaWdpbmF0aW5nIGZyb20gSVAgYWRkcmVzc2VzIG9y IHByZWZpeGVzIHRoYXQgYXJlIGNvbnNpZGVyZWQgc3VzcGVjdAogICBiZWNhdXNlIG9mIG11 bHRpcGxlIGNvbmN1cnJlbnQgaGFsZi1vcGVuIFNBcy4KCiAgICA1LiAgUmF0ZSBMaW1pdGlu ZwoKICAgRXZlbiB3aXRoIEREb1MsIHRoZSBhdHRhY2tlciBoYXMgb25seSBhIGxpbWl0ZWQg YW1vdW50IG9mIG5vZGVzCiAgIHBhcnRpY2lwYXRpbmcgaW4gdGhlIGF0dGFjay4gIEJ5IGxp bWl0aW5nIHRoZSBhbW91bnQgb2YgaGFsZi1vcGVuIFNBcwogICB0aGF0IGFyZSBhbGxvd2Vk IHRvIGV4aXN0IGNvbmN1cnJlbnRseSB3aXRoIGVhY2ggc3VjaCBub2RlLCB0aGUgdG90YWwK ICAgYW1vdW50IG9mIGhhbGYtb3BlbiBTQXMgaXMgY2FwcGVkLCBhcyBpcyB0aGUgdG90YWwg YW1vdW50IG9mIGtleQogICBkZXJpdmF0aW9ucyB0aGF0IHRoZSBSZXNwb25kZXIgaXMgZm9y Y2VkIHRvIGNvbXBsZXRlLgoKICAgSW4gSVB2NCBpdCBtYWtlcyBzZW5zZSB0byBsaW1pdCB0 aGUgbnVtYmVyIG9mIGhhbGYtb3BlbiBTQXMgYmFzZWQgb24KICAgSVAgYWRkcmVzcy4gIE1v c3QgSVB2NCBub2RlcyBhcmUgZWl0aGVyIGRpcmVjdGx5IGF0dGFjaGVkIHRvIHRoZQogICBJ bnRlcm5ldCB1c2luZyBhIHJvdXRhYmxlIGFkZHJlc3Mgb3IgYXJlIGhpZGRlbiBiZWhpbmQg YSBOQVQgZGV2aWNlCiAgIHdpdGggYSBzaW5nbGUgSVB2NCBleHRlcm5hbCBhZGRyZXNzLiAg SVB2NiBuZXR3b3JrcyBhcmUgY3VycmVudGx5IGEKICAgcmFyaXR5LCBzbyB3ZSBjYW4gb25s eSBzcGVjdWxhdGUgb24gd2hhdCB0aGVpciB3aWRlIGRlcGxveW1lbnQgd2lsbAogICBiZSBs aWtlLCBidXQgdGhlIGN1cnJlbnQgdGhpbmtpbmcgaXMgdGhhdCBJU1AgY3VzdG9tZXJzIHdp bGwgYmUKICAgYXNzaWduZWQgd2hvbGUgc3VibmV0cywgc28gd2UgZG9uJ3QgZXhwZWN0IHRo ZSBraW5kIG9mIE5BVCBkZXBsb3ltZW50CiAgIHRoYXQgaXMgY29tbW9uIGluIElQdjQuICBG b3IgdGhpcyByZWFzb24sIGl0IG1ha2VzIHNlbnNlIHRvIHVzZSBhCiAgIDY0LWJpdCBwcmVm aXggYXMgdGhlIGJhc2lzIGZvciByYXRlIGxpbWl0aW5nIGluIElQdjYuCgogICBUaGUgbnVt YmVyIG9mIGhhbGYtb3BlbiBTQXMgaXMgZWFzeSB0byBtZWFzdXJlLCBidXQgaXQgaXMgYWxz bwogICB3b3J0aHdoaWxlIHRvIG1lYXN1cmUgdGhlIG51bWJlciBvZiBmYWlsZWQgSUtFX0FV VEggZXhjaGFuZ2VzLiAgSWYKICAgcG9zc2libGUsIGJvdGggZmFjdG9ycyBzaG91bGQgYmUg dGFrZW4gaW50byBhY2NvdW50IHdoZW4gZGVjaWRpbmcKICAgd2hpY2ggSVAgYWRkcmVzcyBv ciBwcmVmaXggaXMgY29uc2lkZXJlZCBzdXNwaWNpb3VzLgoKICAgVGhlcmUgYXJlIHR3byB3 YXlzIHRvIHJhdGUtbGltaXQgYSBwZWVyIGFkZHJlc3Mgb3IgcHJlZml4OgoKICAgICAgIDEu ICBIYXJkIExpbWl0IC0gd2hlcmUgdGhlIG51bWJlciBvZiBoYWxmLW9wZW4gU0FzIGlzIGNh cHBlZCwgYW5kCiAgICAgICBhbnkgZnVydGhlciBJS0VfU0FfSU5JVCByZXF1ZXN0cyBhcmUg cmVqZWN0ZWQuCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRl bWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIw MTYKCgogICAyLiAgU29mdCBMaW1pdCAtIHdoZXJlIGlmIGEgc2V0IG51bWJlciBvZiBoYWxm LW9wZW4gU0FzIGV4aXN0IGZvciBhCiAgICAgICBwYXJ0aWN1bGFyIGFkZHJlc3Mgb3IgcHJl Zml4LCBhbnkgSUtFX1NBX0lOSVQgcmVxdWVzdCB3aWxsCiAgICAgICByZXF1aXJlIHNvbHZp bmcgYSBwdXp6bGUuCgogICBUaGUgYWR2YW50YWdlIG9mIHRoZSBoYXJkIGxpbWl0IG1ldGhv ZCBpcyB0aGF0IGl0IHByb3ZpZGVzIGEgaGFyZCBjYXAKICAgb24gdGhlIGFtb3VudCBvZiBo YWxmLW9wZW4gU0FzIHRoYXQgdGhlIGF0dGFja2VyIGlzIGFibGUgdG8gY3JlYXRlLgogICBU aGUgZG93bnNpZGUgaXMgdGhhdCBpdCBhbGxvd3MgdGhlIGF0dGFja2VyIHRvIGJsb2NrIElL RSBpbml0aWF0aW9uCiAgIGZyb20gc21hbGwgcGFydHMgb2YgdGhlIEludGVybmV0LiAgRm9y IGV4YW1wbGUsIGlmIGFuIG5ldHdvcmsgc2VydmljZQogICBwcm92aWRlciBvciBzb21lIGVz dGFibGlzaG1lbnQgb2ZmZXJzIEludGVybmV0IGNvbm5lY3Rpdml0eSB0byBpdHMKICAgY3Vz dG9tZXJzIG9yIGVtcGxveWVlcyB0aHJvdWdoIGFuIElQdjQgTkFUIGRldmljZSwgYSBzaW5n bGUgbWFsaWNpb3VzCiAgIGN1c3RvbWVyIGNhbiBjcmVhdGUgZW5vdWdoIGhhbGYtb3BlbiBT QXMgdG8gZmlsbCB0aGUgcXVvdGEgZm9yIHRoZQogICBOQVQgZGV2aWNlIGV4dGVybmFsIElQ IGFkZHJlc3MuICBMZWdpdGltYXRlIEluaXRpYXRvcnMgb24gdGhlIHNhbWUKICAgbmV0d29y ayB3aWxsIG5vdCBiZSBhYmxlIHRvIGluaXRpYXRlIElLRS4KCiAgIFRoZSBhZHZhbnRhZ2Ug b2YgYSBzb2Z0IGxpbWl0IGlzIHRoYXQgbGVnaXRpbWF0ZSBjbGllbnRzIGNhbiBhbHdheXMK ICAgY29ubmVjdC4gIFRoZSBkaXNhZHZhbnRhZ2UgaXMgdGhhdCBhbiBhZHZlcnNhcnkgd2l0 aCBzdWZmaWNpZW50IENQVQogICByZXNvdXJjZXMgY2FuIHN0aWxsIGVmZmVjdGl2ZWx5IERv UyB0aGUgUmVzcG9uZGVyLgoKICAgUmVnYXJkbGVzcyBvZiB0aGUgdHlwZSBvZiByYXRlLWxp bWl0aW5nIHVzZWQsIHRoZXJlIGlzIGEgaHVnZQogICBhZHZhbnRhZ2UgaW4gYmxvY2tpbmcg dGhlIERvUyBhdHRhY2sgdXNpbmcgcmF0ZS1saW1pdGluZyBmb3IKICAgbGVnaXRpbWF0ZSBj bGllbnRzIHRoYXQgYXJlIGF3YXkgZnJvbSB0aGUgYXR0YWNraW5nIG5vZGVzLiAgSW4gc3Vj aAogICBjYXNlcywgYWR2ZXJzZSBpbXBhY3RzIGNhdXNlZCBieSB0aGUgYXR0YWNrIG9yIGJ5 IHRoZSBtZWFzdXJlcyB1c2VkCiAgIHRvIGNvdW50ZXJhY3QgdGhlIGF0dGFjayBjYW4gYmUg YXZvaWRlZC4KCiAgICA2LiAgUGxhbiBmb3IgRGVmZW5kaW5nIGEgUmVzcG9uZGVyCgogICBU aGlzIHNlY3Rpb24gb3V0bGluZXMgYSBwbGFuIGZvciBkZWZlbmRpbmcgYSBSZXNwb25kZXIg ZnJvbSBhIEREb1MKICAgYXR0YWNrIGJhc2VkIG9uIHRoZSB0ZWNobmlxdWVzIGRlc2NyaWJl ZCBlYXJsaWVyLiAgVGhlIG51bWJlcnMgZ2l2ZW4KICAgaGVyZSBhcmUgbm90IG5vcm1hdGl2 ZSwgYW5kIHRoZWlyIHB1cnBvc2UgaXMgdG8gaWxsdXN0cmF0ZSB0aGUKICAgY29uZmlndXJh YmxlIHBhcmFtZXRlcnMgbmVlZGVkIGZvciBkZWZlYXRpbmcgdGhlIEREb1MgYXR0YWNrLgoK ICAgSW1wbGVtZW50YXRpb25zIG1heSBiZSBkZXBsb3llZCBpbiBkaWZmZXJlbnQgZW52aXJv bm1lbnRzLCBzbyBpdCBpcwogICBSRUNPTU1FTkRFRCB0aGF0IHRoZSBwYXJhbWV0ZXJzIGJl IHNldHRhYmxlLiAgQXMgYW4gZXhhbXBsZSwgbW9zdAogICBjb21tZXJjaWFsIHByb2R1Y3Rz IGFyZSByZXF1aXJlZCB0byB1bmRlcmdvIGJlbmNobWFya2luZyB3aGVyZSB0aGUKICAgSUtF IFNBIGVzdGFibGlzaG1lbnQgcmF0ZSBpcyBtZWFzdXJlZC4gIEJlbmNobWFya2luZyBpcwog ICBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIGEgRG9TIGF0dGFjayBhbmQgdGhlIGRlZmVuc2Vz IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG1heSBkZWZlYXQgdGhlIGJlbmNobWFy ayBieSBjYXVzaW5nIGV4Y2hhbmdlcyB0byBmYWlsCiAgIG9yIHRha2UgYSBsb25nIHRpbWUg dG8gY29tcGxldGUuICBQYXJhbWV0ZXJzIHNob3VsZCBiZSB0dW5hYmxlIHRvCiAgIGFsbG93 IGZvciBiZW5jaG1hcmtpbmcgKGlmIG9ubHkgYnkgdHVybmluZyBERG9TIHByb3RlY3Rpb24g b2ZmKS4KCiAgIFNpbmNlIGFsbCBjb3VudGVybWVhc3VyZXMgbWF5IGNhdXNlIGRlbGF5cyBh bmQgd29yayBvbiB0aGUKICAgSW5pdGlhdG9ycywgdGhleSBTSE9VTEQgTk9UIGJlIGRlcGxv eWVkIHVubGVzcyBhbiBhdHRhY2sgaXMgbGlrZWx5IHRvCiAgIGJlIGluIHByb2dyZXNzLiAg VG8gbWluaW1pemUgdGhlIGJ1cmRlbiBpbXBvc2VkIG9uIEluaXRpYXRvcnMsIHRoZQogICBS ZXNwb25kZXIgc2hvdWxkIG1vbml0b3IgaW5jb21pbmcgSUtFIHJlcXVlc3RzLCBzZWFyY2hp bmcgZm9yIHR3bwogICB0aGluZ3M6CgogICAgICAgMS4gIEEgZ2VuZXJhbCBERG9TIGF0dGFj ay4gIFN1Y2ggYW4gYXR0YWNrIGlzIGluZGljYXRlZCBieSBhIGhpZ2gKICAgICAgIG51bWJl ciBvZiBjb25jdXJyZW50IGhhbGYtb3BlbiBTQXMsIGEgaGlnaCByYXRlIG9mIGZhaWxlZAog CgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFBy b3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgICAgIElL RV9BVVRIIGV4Y2hhbmdlcywgb3IgYSBjb21iaW5hdGlvbiBvZiBib3RoLiAgRm9yIGV4YW1w bGUsCiAgICAgICBjb25zaWRlciBhIFJlc3BvbmRlciB0aGF0IGhhcyAxMCwwMDAgZGlzdGlu Y3QgcGVlcnMgb2Ygd2hpY2ggYXQKICAgICAgIHBlYWsgNyw1MDAgY29uY3VycmVudGx5IGhh dmUgVlBOIHR1bm5lbHMuICBBdCB0aGUgc3RhcnQgb2YgcGVhawogICAgICAgdGltZSwgNjAw IHBlZXJzIG1pZ2h0IGVzdGFibGlzaCB0dW5uZWxzIGF0IGFueSBnaXZlbiBtaW51dGUsIGFu ZAogICAgICAgdHVubmVsIGVzdGFibGlzaG1lbnQgKGJvdGggSUtFX1NBX0lOSVQgYW5kIElL RV9BVVRIKSB0YWtlcwogICAgICAgYW55d2hlcmUgZnJvbSAwLjUgdG8gMiBzZWNvbmRzLiAg Rm9yIHRoaXMgUmVzcG9uZGVyLCB3ZSBleHBlY3QKICAgICAgIHRoZXJlIHRvIGJlIGxlc3Mg dGhhbiAyMCBjb25jdXJyZW50IGhhbGYtb3BlbiBTQXMsIHNvIGhhdmluZyAxMDAKICAgICAg IGNvbmN1cnJlbnQgaGFsZi1vcGVuIFNBcyBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYW4gaW5k aWNhdGlvbiBvZgogICAgICAgYW4gYXR0YWNrLiAgU2ltaWxhcmx5LCBJS0VfQVVUSCByZXF1 ZXN0IGRlY3J5cHRpb24gZmFpbHVyZXMKICAgICAgIHNob3VsZCBuZXZlciBoYXBwZW4uICBT dXBwb3NpbmcgdGhlIHRoZSB0dW5uZWxzIGFyZSBlc3RhYmxpc2hlZAogICAgICAgdXNpbmcg RUFQIChzZWUgU2VjdGlvbiAyLjE2IG9mIFtSRkM3Mjk2XSksIHVzZXJzIGVudGVyIHRoZSB3 cm9uZwogICAgICAgcGFzc3dvcmQgYWJvdXQgMjAlIG9mIHRoZSB0aW1lLiAgU28gd2UnZCBl eHBlY3QgMTI1IHdyb25nCiAgICAgICBwYXNzd29yZCBmYWlsdXJlcyBhIG1pbnV0ZS4gIElm IHdlIGdldCBJS0VfQVVUSCBkZWNyeXB0aW9uCiAgICAgICBmYWlsdXJlcyBmcm9tIG11bHRp cGxlIHNvdXJjZXMgbW9yZSB0aGFuIG9uY2UgcGVyIHNlY29uZCwgb3IgRUFQCiAgICAgICBm YWlsdXJlIG1vcmUgdGhhbiAzMDAgdGltZXMgcGVyIG1pbnV0ZSwgdGhhdCBjYW4gYWxzbyBi ZSBhbgogICAgICAgaW5kaWNhdGlvbiBvZiBhIEREb1MgYXR0YWNrLgoKICAgICAgIDIuICBB biBhdHRhY2sgZnJvbSBhIHBhcnRpY3VsYXIgSVAgYWRkcmVzcyBvciBwcmVmaXguICBTdWNo IGFuCiAgICAgICBhdHRhY2sgaXMgaW5kaWNhdGVkIGJ5IGFuIGlub3JkaW5hdGUgYW1vdW50 IG9mIGhhbGYtb3BlbiBTQXMgZnJvbQogICAgICAgdGhhdCBJUCBhZGRyZXNzIG9yIHByZWZp eCwgb3IgYW4gaW5vcmRpbmF0ZSBhbW91bnQgb2YgSUtFX0FVVEgKICAgICAgIGZhaWx1cmVz LiAgQSBERG9TIGF0dGFjayBtYXkgYmUgdmlld2VkIGFzIG11bHRpcGxlIHN1Y2ggYXR0YWNr cy4KICAgICAgIElmIHRoZXkgYXJlIG1pdGlnYXRlZCB3ZWxsIGVub3VnaCwgdGhlcmUgd2ls bCBub3QgYmUgYSBuZWVkIGVuYWN0CiAgICAgICBjb3VudGVybWVhc3VyZXMgb24gYWxsIElu aXRpYXRvcnMuICBUeXBpY2FsIG1lYXN1cmVzIG1pZ2h0IGJlIDUKICAgICAgIGNvbmN1cnJl bnQgaGFsZi1vcGVuIFNBcywgMSBkZWNyeXB0IGZhaWx1cmUsIG9yIDEwIEVBUCBmYWlsdXJl cwogICAgICAgd2l0aGluIGEgbWludXRlLgoKICAgTm90ZSB0aGF0IHVzaW5nIGNvdW50ZXIt bWVhc3VyZXMgYWdhaW5zdCBhbiBhdHRhY2sgZnJvbSBhIHBhcnRpY3VsYXIKICAgSVAgYWRk cmVzcyBtYXkgYmUgZW5vdWdoIHRvIGF2b2lkIHRoZSBvdmVybG9hZCBvbiB0aGUgaGFsZi1v cGVuIFNBCiAgIGRhdGFiYXNlIGFuZCBpbiB0aGlzIGNhc2UgdGhlIG51bWJlciBvZiBmYWls ZWQgSUtFX0FVVEggZXhjaGFuZ2VzCiAgIG5ldmVyIGV4Y2VlZHMgdGhlIHRocmVzaG9sZCBv ZiBhdHRhY2sgZGV0ZWN0aW9uLiAgVGhpcyBpcyBhIGdvb2QKICAgdGhpbmcgYXMgaXQgcHJl dmVudHMgSW5pdGlhdG9ycyB0aGF0IGFyZSBub3QgY2xvc2UgdG8gdGhlIGF0dGFja2Vycwog ICBmcm9tIGJlaW5nIGFmZmVjdGVkLgoKICAgV2hlbiB0aGVyZSBpcyBubyBnZW5lcmFsIERE b1MgYXR0YWNrLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCBubyBjb29raWUKICAgb3IgcHV6emxl cyBiZSB1c2VkLiAgQXQgdGhpcyBwb2ludCB0aGUgb25seSBkZWZlbnNpdmUgbWVhc3VyZSBp cyB0aGUKICAgbW9uaXRvcmluZyBvZiB0aGUgbnVtYmVyIG9mIGhhbGYtb3BlbiBTQXMsIGFu ZCBzZXR0aW5nIGEgc29mdCBsaW1pdAogICBwZXIgcGVlciBJUCBvciBwcmVmaXguICBUaGUg c29mdCBsaW1pdCBjYW4gYmUgc2V0IHRvIDMtNSwgYW5kIHRoZQogICBwdXp6bGUgZGlmZmlj dWx0eSBzaG91bGQgYmUgc2V0IHRvIHN1Y2ggYSBsZXZlbCAobnVtYmVyIG9mIHplcm8tYml0 cykKICAgdGhhdCBhbGwgbGVnaXRpbWF0ZSBjbGllbnRzIGNhbiBoYW5kbGUgaXQgd2l0aG91 dCBkZWdyYWRlZCB1c2VyCiAgIGV4cGVyaWVuY2UuCgogICBBcyBzb29uIGFzIGFueSBraW5k IG9mIGF0dGFjayBpcyBkZXRlY3RlZCwgZWl0aGVyIGEgbG90IG9mCiAgIGluaXRpYXRpb25z IGZyb20gbXVsdGlwbGUgc291cmNlcyBvciBhIGxvdCBvZiBpbml0aWF0aW9ucyBmcm9tIGEg ZmV3CiAgIHNvdXJjZXMsIGl0IGlzIGJlc3QgdG8gYmVnaW4gYnkgcmVxdWlyaW5nIHN0YXRl bGVzcyBjb29raWVzIGZyb20gYWxsCiAgIEluaXRpYXRvcnMuICBUaGlzIHdpbGwgZm9yY2Ug dGhlIGF0dGFja2VyIHRvIHVzZSByZWFsIHNvdXJjZQogICBhZGRyZXNzZXMsIGFuZCBoZWxw IGF2b2lkIHRoZSBuZWVkIHRvIGltcG9zZSBhIGdyZWF0ZXIgYnVyZGVuIGluIHRoZQogICBm b3JtIG9mIGNvb2tpZXMgb24gdGhlIGdlbmVyYWwgcG9wdWxhdGlvbiBvZiBJbml0aWF0b3Jz LiAgVGhpcyBtYWtlcwogICB0aGUgcGVyLW5vZGUgb3IgcGVyLXByZWZpeCBzb2Z0IGxpbWl0 IG1vcmUgZWZmZWN0aXZlLgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBT ZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJj aCAyMDE2CgoKICAgV2hlbiBjb29raWVzIGFyZSBhY3RpdmF0ZWQgZm9yIGFsbCByZXF1ZXN0 cyBhbmQgdGhlIGF0dGFja2VyIGlzIHN0aWxsCiAgIG1hbmFnaW5nIHRvIGNvbnN1bWUgdG9v IG1hbnkgcmVzb3VyY2VzLCB0aGUgUmVzcG9uZGVyIE1BWSBpbmNyZWFzZQogICB0aGUgZGlm ZmljdWx0eSBvZiBwdXp6bGVzIGltcG9zZWQgb24gSUtFX1NBX0lOSVQgcmVxdWVzdHMgY29t aW5nIGZyb20KICAgc3VzcGljaW91cyBub2Rlcy9wcmVmaXhlcy4gIEl0IHNob3VsZCBzdGls bCBiZSBkb2FibGUgYnkgYWxsCiAgIGxlZ2l0aW1hdGUgcGVlcnMsIGJ1dCBpdCBjYW4gZGVn cmFkZSBleHBlcmllbmNlLCBmb3IgZXhhbXBsZSBieQogICB0YWtpbmcgdXAgdG8gMTAgc2Vj b25kcyB0byBzb2x2ZSB0aGUgcHV6emxlLgoKICAgSWYgdGhlIGxvYWQgb24gdGhlIFJlc3Bv bmRlciBpcyBzdGlsbCB0b28gZ3JlYXQsIGFuZCB0aGVyZSBhcmUgbWFueQogICBub2RlcyBj YXVzaW5nIG11bHRpcGxlIGhhbGYtb3BlbiBTQXMgb3IgSUtFX0FVVEggZmFpbHVyZXMsIHRo ZQogICBSZXNwb25kZXIgTUFZIGltcG9zZSBoYXJkIGxpbWl0cyBvbiB0aG9zZSBub2Rlcy4K CiAgIElmIGl0IHR1cm5zIG91dCB0aGF0IHRoZSBhdHRhY2sgaXMgdmVyeSB3aWRlc3ByZWFk IGFuZCB0aGUgaGFyZCBjYXBzCiAgIGFyZSBub3Qgc29sdmluZyB0aGUgaXNzdWUsIGEgcHV6 emxlIE1BWSBiZSBpbXBvc2VkIG9uIGFsbCBJbml0aWF0b3JzLgogICBOb3RlIHRoYXQgdGhp cyBpcyB0aGUgbGFzdCBzdGVwLCBhbmQgdGhlIFJlc3BvbmRlciBzaG91bGQgYXZvaWQgdGhp cwogICBpZiBwb3NzaWJsZS4KCiAgICAgIDYuMS4gIFNlc3Npb24gUmVzdW1wdGlvbgoKICAg V2hlbiB0aGUgUmVzcG9uZGVyIGlzIHVuZGVyIGF0dGFjaywgaXQgTUFZIGNob29zZSB0byBw cmVmZXIKICAgcHJldmlvdXNseSBhdXRoZW50aWNhdGVkIHBlZXJzIHdobyBwcmVzZW50IGEg U2Vzc2lvbiBSZXN1bXB0aW9uCiAgIHRpY2tldCAoc2VlIFtSRkM1NzIzXSBmb3IgZGV0YWls cykuICBUaGUgUmVzcG9uZGVyIE1BWSByZXF1aXJlIHN1Y2gKICAgSW5pdGlhdG9ycyB0byBw YXNzIGEgcmV0dXJuIHJvdXRhYmlsaXR5IGNoZWNrIGJ5IGluY2x1ZGluZyB0aGUgQ09PS0lF CiAgIG5vdGlmaWNhdGlvbiBpbiB0aGUgSUtFX1NFU1NJT05fUkVTVU1FIHJlc3BvbnNlIG1l c3NhZ2UsIGFzIGFsbG93ZWQKICAgYnkgU2VjdGlvbiA0LjMuMi4gb2YgW1JGQzU3MjNdLiAg Tm90ZSB0aGF0IHRoZSBSZXNwb25kZXIgU0hPVUxEIGNhY2hlCiAgIHRpY2tldHMgZm9yIGEg c2hvcnQgdGltZSB0byByZWplY3QgcmV1c2VkIHRpY2tldHMgKFNlY3Rpb24gNC4zLjEpLAog ICBhbmQgdGhlcmVmb3JlIHRoZXJlIHNob3VsZCBiZSBubyBpc3N1ZSBvZiBoYWxmLW9wZW4g U0FzIHJlc3VsdGluZwogICBmcm9tIHJlcGxheWVkIElLRV9TRVNTSU9OX1JFU1VNRSBtZXNz YWdlcy4KCiAgICAgIDYuMi4gSEFTSCBhbmQgVVJMCgogICBSRkMgNzI5NiBkZXNjcmliZXMg dGhlIHVzZSBvZiBhIEhBU0ggYW5kIFVSTCB0byBiZSBzZW50IGluIHBsYWNlIG9mIGEKICAg Y2VydGlmaWNhdGUuIFRoZSB1c2Ugb2YgdGhlIEhBU0ggYW5kIFVSTCBpcyBlbmNvdXJhZ2Vk IHRvIG92ZXJjb21lCiAgIGNvbm5lY3Rpdml0eSBpc3N1ZXMgZHVlIHRvIGZyYWdtZW50YXRp b24gYW5kIGltcHJvdmUgZWZmaWNpZW5jeSB3aGVuCiAgIHNlbmRpbmcgbGFyZ2UgY2VydGlm aWNhdGVzLiAKCiAgIFdoZW4gYSBjbGllbnQgaXMgdXNpbmcgdGhlIEhBU0ggYW5kIFVSTCBt ZXRob2QgaW5zdGVhZCBvZiBzZW5kaW5nIGEKICAgY2VydGlmaWNhdGUsIHRoZSBlbXBoYXNp cyBpcyBvbiB0aGUgVlBOIGdhdGV3YXkgdG8gcmV0cmlldmUgdGhlCiAgIGNlcnRpZmljYXRl IGFuZCB0aGVuIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCB0aGlzIGlzIGNvbnRyYXJ5IHRv IHRoZQogICBjbGllbnQgc2VuZGluZyBpdHMgb3duIGNlcnRpZmljYXRlLCB3aGljaCBpcyB0 aGUgcmVzcG9uc2liaWxpdHkgb2YKICAgdGhlIGNsaWVudC4gQmVjYXVzZSB0aGUgZW1waGFz aXMgaXMgb24gdGhlIFZQTiBnYXRld2F5IHRvIHJldHJpZXZlCiAgIHRoZSBjZXJ0aWZpY2F0 ZSBtYWxpY2lvdXMgY2xpZW50cyBjYW4gdXNlIHRoaXMgYXMgYSBtZXRob2QgZm9yIERvUwog ICBjb25kaXRpb25zLgoKICAgQmVjYXVzZSBtYW55IGltcGxlbWVudGF0aW9uIGRvIG5vdCB1 c2UgdGhlIEhBU0ggYW5kIFVSTCwKICAgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBoYXZlIHRo ZSBhYmlsaXR5IHRvIGRpc2FibGUgdGhlIHVzZSBvZiBIQVNICiAgIGFuZCBVUkwgaWYgdGhp cyBmZWF0dXJlIGlzIG5vdCBjb25maWd1cmVkLiBUaGlzIHdpbGwgbWluaW1pemUgdGhlCiAg IGltcGFjdCBvZiBkYW1hZ2UgZnJvbSBtYWxpY2lvdXMgdXNlLgoKIAoKCk5pciAmIFNteXNs b3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQ YWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJ S0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIEEgbnVtYmVyIG9mIGF0dGFja3Mg Y2FuIG9jY3VyIGlmIGltcGxlbWVudGF0aW9ucyB1c2UgdGhlIEhBU0ggYW5kCiAgIFVSTCwg bWFsaWNpb3VzIHBhcnRpZXMgY2FuIHNlbmQgYSBVUkwgdG8gcmVkaXJlY3QgYSBWUE4gZ2F0 ZXdheSB0byBhCiAgIHNlcnZlciB3aGljaCBkb2VzIG5vdCBjb250YWluIHRoZSBIQVNIIG9m IHRoZSBjZXJ0aWZpY2F0ZSwgYnV0CiAgIGluc3RlYWQgY29udGFpbnMgYSBsYXJnZSBmaWxl IHRoYXQgaXMgdGhlbiBkb3dubG9hZGVkIGJ5IHRoZSBWUE4KICAgZ2F0ZXdheSBjb25zdW1p bmcgQ1BVIGFuZCBtZW1vcnkuIEZvciB0aGlzIHJlYXNvbiB0aGUgc2l6ZSBvZiBmaWxlCiAg IHB1bGxlZCBieSB0aGUgc2VydmVyIFNIT1VMRCBiZSBsaW1pdGVkIHRvIGEgY2VydGFpbiB2 YWx1ZSBkaWN0YXRlZCBieQogICB0aGUgcG9saWN5IGZvciB0aGUgaXNzdWluZyBDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkuIFRoZSBWUE4gZ2F0ZXdheQogICBTSE9VTEQgYmUgY29uZmlndXJh YmxlIHRvIG9ubHkgcmV0cmlldmUgVVJMcyBmcm9tIGtub3duIGdvb2Qgc291cmNlcywKICAg dGhlcmUgaXMgbm8gcG9pbnQgaW4gdGhlIFZQTiBnYXRld2F5IGF0dGVtcHRpbmcgdG8gcmV0 cmlldmUgYQogICBjZXJ0aWZpY2F0ZSBmcm9tIGEgbG9jYXRpb24gdGhhdCBpcyBub3Qga25v d24gdG8gYmUgYSByZXBvc2l0b3J5IG9mCiAgIGNlcnRpZmljYXRlcy4KCiAgIE1hbGljaW91 cyBvciBtaXMtY29uZmlndXJlZCBjbGllbnRzIGNhbiBtYWtlIG51bWVyb3VzIHJlcXVlc3Rz IHRoYXQKICAgZXhoYXVzdCB0aGUgSFRUUCBvciBUQ1AgZGFlbW9uIHJ1bm5pbmcgb24gdGhl IFZQTiBnYXRld2F5LiBUaGUgYW1vdW50CiAgIG9mIHJlcXVlc3RzIHRoYXQgYXJlIHBlcmZv cm1lZCBpbiBhIGdpdmVuIHRpbWUgc2hvdWxkIGJlIG1vbml0b3JlZAogICBhbmQgcmF0ZSBs aW1pdGVkIHNob3VsZCBIVFRQIGNvbm5lY3Rpb25zIGZhaWwuIFRoZSBWUE4gZ2F0ZXdheQog ICBhcmNoaXRlY3R1cmUgc2hvdWxkIGJlIGRlc2lnbmVkIHNvIHRoYXQgdGhlIHJlcG9zaXRv cnkgY29udGFpbmluZwogICBjZXJ0aWZpY2F0ZXMgaXMgb24gdGhlIHByb3RlY3RlZCBpbnRl cmZhY2Ugb2YgdGhlIFZQTiBnYXRld2F5LiBUaGlzCiAgIG1pbmltaXplcyB0aGUgcmlzayBv ZiB0aGUgcmVwb3NpdG9yeSBiZWluZyBjb21wcm9taXNlZCBhbmQgYXR0YWNrcwogICBzdWNo IGFzIG9wZW5pbmcgc29ja2V0cyBhbmQgdGhlbiBzZXR0aW5nIGEgemVybyB3aW5kb3cgc2l6 ZSBiZWluZwogICBwZXJmb3JtZWQuCgogICAgNy4gIFVzaW5nIFB1enpsZXMgaW4gdGhlIFBy b3RvY29sCgogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0aGUgcHV6emxlIG1lY2hh bmlzbSBpcyB1c2VkIGluIElLRXYyLiAgSXQKICAgaXMgb3JnYW5pemVkIGFzIGZvbGxvd3Mu ICBUaGUgU2VjdGlvbiA3LjEgZGVzY3JpYmVzIHVzaW5nIHB1enpsZXMgaW4KICAgdGhlIElL RV9TQV9JTklUIGV4Y2hhbmdlIGFuZCB0aGUgU2VjdGlvbiA3LjIgZGVzY3JpYmVzIHVzaW5n IHB1enpsZXMKICAgaW4gdGhlIElLRV9BVVRIIGV4Y2hhbmdlLiAgQm90aCBzZWN0aW9ucyBh cmUgZGl2aWRlZCBpbnRvIHN1YnNlY3Rpb25zCiAgIGRlc2NyaWJpbmcgaG93IHB1enpsZXMg c2hvdWxkIGJlIHByZXNlbnRlZCwgc29sdmVkIGFuZCBwcm9jZXNzZWQgYnkKICAgdGhlIElu aXRpYXRvciBhbmQgdGhlIFJlc3BvbmRlci4KCiAgICAgIDcuMS4gIFB1enpsZXMgaW4gSUtF X1NBX0lOSVQgRXhjaGFuZ2UKCiAgIElLRSBJbml0aWF0b3IgaW5kaWNhdGVzIHRoZSBkZXNp cmUgdG8gY3JlYXRlIGEgbmV3IElLRSBTQSBieSBzZW5kaW5nCiAgIElLRV9TQV9JTklUIHJl cXVlc3QgbWVzc2FnZS4gIFRoZSBtZXNzYWdlIG1heSBvcHRpb25hbGx5IGNvbnRhaW4gYQog ICBDT09LSUUgbm90aWZpY2F0aW9uIGlmIHRoaXMgaXMgYSByZXBlYXRlZCByZXF1ZXN0IHBl cmZvcm1lZCBhZnRlciB0aGUKICAgUmVzcG9uZGVyJ3MgZGVtYW5kIHRvIHJldHVybiBhIGNv b2tpZS4KCiAgIEhEUiwgW04oQ09PS0lFKSxdIFNBLCBLRSwgTmksIFtWK11bTitdICAgLS0+ CgogICBBY2NvcmRpbmcgdG8gdGhlIHBsYW4sIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYsIHRo ZSBJS0UgUmVzcG9uZGVyCiAgIHNob3VsZCBtb25pdG9yIGluY29taW5nIHJlcXVlc3RzIHRv IGRldGVjdCB3aGV0aGVyIGl0IGlzIHVuZGVyCgoKCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYg QmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAx NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIg ICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBhdHRhY2suICBJZiB0aGUgUmVzcG9uZGVy IGxlYXJucyB0aGF0IChEKURvUyBhdHRhY2sgaXMgbGlrZWx5IHRvIGJlCiAgIGluIHByb2dy ZXNzLCB0aGVuIGl0cyBhY3Rpb25zIGRlcGVuZCBvbiB0aGUgdm9sdW1lIG9mIHRoZSBhdHRh Y2suICBJZgogICB0aGUgdm9sdW1lIGlzIG1vZGVyYXRlLCB0aGVuIHRoZSBSZXNwb25kZXIg cmVxdWVzdHMgdGhlIEluaXRpYXRvciB0bwogICByZXR1cm4gYSBjb29raWUuICBJZiB0aGUg dm9sdW1lIGlzIHNvIGhpZ2gsIHRoYXQgcHV6emxlcyBuZWVkIHRvIGJlCiAgIHVzZWQgZm9y IGRlZmVuc2UsIHRoZW4gdGhlIFJlc3BvbmRlciByZXF1ZXN0cyB0aGUgSW5pdGlhdG9yIHRv IHNvbHZlCiAgIGEgcHV6emxlLgoKICAgVGhlIFJlc3BvbmRlciBNQVkgY2hvb3NlIHRvIHBy b2Nlc3Mgc29tZSBmcmFjdGlvbiBvZiBJS0VfU0FfSU5JVAogICByZXF1ZXN0cyB3aXRob3V0 IHByZXNlbnRpbmcgYSBwdXp6bGUgd2hpbGUgYmVpbmcgdW5kZXIgYXR0YWNrIHRvCiAgIGFs bG93IGxlZ2FjeSBjbGllbnRzLCB0aGF0IGRvbid0IHN1cHBvcnQgcHV6emxlcywgdG8gaGF2 ZSBhIGNoYW5jZSB0bwogICBiZSBzZXJ2ZWQuICBUaGUgZGVjaXNpb24gd2hldGhlciB0byBw cm9jZXNzIGFueSBwYXJ0aWN1bGFyIHJlcXVlc3QKICAgbXVzdCBiZSBwcm9iYWJpbGlzdGlj LCB3aXRoIHRoZSBwcm9iYWJpbGl0eSBkZXBlbmRpbmcgb24gdGhlCiAgIFJlc3BvbmRlcidz IGxvYWQgKGkuZS4gb24gdGhlIHZvbHVtZSBvZiBhdHRhY2spLiAgVGhlIHJlcXVlc3RzIHRo YXQKICAgZG9uJ3QgY29udGFpbiB0aGUgQ09PS0lFIG5vdGlmaWNhdGlvbiBNVVNUIE5PVCBw YXJ0aWNpcGF0ZSBpbiB0aGlzCiAgIGxvdHRlcnkuICBJbiBvdGhlciB3b3JkcywgdGhlIFJl c3BvbmRlciBtdXN0IGZpcnN0IHBlcmZvcm0gcmV0dXJuCiAgIHJvdXRhYmlsaXR5IGNoZWNr IGJlZm9yZSBhbGxvd2luZyBhbnkgbGVnYWN5IGNsaWVudCB0byBiZSBzZXJ2ZWQgaWYKICAg aXQgaXMgdW5kZXIgYXR0YWNrLiAgU2VlIFNlY3Rpb24gNy4xLjQgZm9yIGRldGFpbHMuCgog ICAgICAgIDcuMS4xLiAgUHJlc2VudGluZyBQdXp6bGUKCiAgIElmIHRoZSBSZXNwb25kZXIg bWFrZXMgYSBkZWNpc2lvbiB0byB1c2UgcHV6emxlcywgdGhlbiBpdCBNVVNUCiAgIGluY2x1 ZGUgdHdvIG5vdGlmaWNhdGlvbnMgaW4gaXRzIHJlc3BvbnNlIG1lc3NhZ2UgLSB0aGUgQ09P S0lFCiAgIG5vdGlmaWNhdGlvbiBhbmQgdGhlIFBVWlpMRSBub3RpZmljYXRpb24uICBUaGUg Zm9ybWF0IG9mIHRoZSBQVVpaTEUKICAgbm90aWZpY2F0aW9uIGlzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDkuMS4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tICAgSERSLCBO KENPT0tJRSksIE4oUFVaWkxFKSwgW1YrXVtOK10KCiAgIFRoZSBwcmVzZW5jZSBvZiB0aGVz ZSBub3RpZmljYXRpb25zIGluIGFuIElLRV9TQV9JTklUIHJlc3BvbnNlCiAgIG1lc3NhZ2Ug aW5kaWNhdGVzIHRvIHRoZSBJbml0aWF0b3IgdGhhdCBpdCBzaG91bGQgc29sdmUgdGhlIHB1 enpsZSB0bwogICBnZXQgYmV0dGVyIGNoYW5jZXMgdG8gYmUgc2VydmVkLgoKICAgICAgICAg IDcuMS4xLjEuICBTZWxlY3RpbmcgUHV6emxlIERpZmZpY3VsdHkgTGV2ZWwKCiAgIFRoZSBQ VVpaTEUgbm90aWZpY2F0aW9uIGNvbnRhaW5zIHRoZSBkaWZmaWN1bHR5IGxldmVsIG9mIHRo ZSBwdXp6bGUgLQogICB0aGUgbWluaW11bSBudW1iZXIgb2YgdHJhaWxpbmcgemVybyBiaXRz IHRoYXQgdGhlIHJlc3VsdCBvZiBQUkYgbXVzdAogICBjb250YWluLiAgSW4gZGl2ZXJzZSBl bnZpcm9ubWVudHMgaXQgaXMgbmV4dCB0byBpbXBvc3NpYmxlIGZvciB0aGUKICAgUmVzcG9u ZGVyIHRvIHNldCBhbnkgc3BlY2lmaWMgZGlmZmljdWx0eSBsZXZlbCB0aGF0IHdpbGwgcmVz dWx0IGluCiAgIHJvdWdobHkgdGhlIHNhbWUgYW1vdW50IG9mIHdvcmsgZm9yIGFsbCBJbml0 aWF0b3JzLCBiZWNhdXNlCiAgIGNvbXB1dGF0aW9uIHBvd2VyIG9mIGRpZmZlcmVudCBJbml0 aWF0b3JzIG1heSB2YXJ5IGJ5IHRoZSBvcmRlciBvZgogICBtYWduaXR1ZGUsIG9yIGV2ZW4g bW9yZS4gIFRoZSBSZXNwb25kZXIgbWF5IHNldCBkaWZmaWN1bHR5IGxldmVsIHRvCiAgIDAs IG1lYW5pbmcgdGhhdCB0aGUgSW5pdGlhdG9yIGlzIHJlcXVlc3RlZCB0byBzcGVuZCBhcyBt dWNoIHBvd2VyIHRvCiAgIHNvbHZlIHB1enpsZSwgYXMgaXQgY2FuIGFmZm9yZC4gIEluIHRo aXMgY2FzZSBubyBzcGVjaWZpYyB2YWx1ZSBvZgogICBaQkMgaXMgcmVxdWlyZWQgZnJvbSB0 aGUgSW5pdGlhdG9yLCBob3dldmVyIHRoZSBsYXJnZXIgdGhlIFpCQyB0aGF0CiAgIEluaXRp YXRvciBpcyBhYmxlIHRvIGdldCwgdGhlIGJldHRlciB0aGUgY2hhbmNlcyBpdCB3aWxsIGhh dmUgdG8gYmUKICAgc2VydmVkIGJ5IHRoZSBSZXNwb25kZXIuICBJbiBkaXZlcnNlIGVudmly b25tZW50cyBpdCBpcyBSRUNPTU1FTkRFRAogICB0aGF0IHRoZSBJbml0aWF0b3Igc2V0cyBk aWZmaWN1bHR5IGxldmVsIHRvIDAsIHVubGVzcyB0aGUgYXR0YWNrCiAgIHZvbHVtZSBpcyB2 ZXJ5IGhpZ2guCgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1i ZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2 CgoKICAgSWYgdGhlIFJlc3BvbmRlciBzZXRzIG5vbi16ZXJvIGRpZmZpY3VsdHkgbGV2ZWws IHRoZW4gdGhlIGxldmVsCiAgIHNob3VsZCBiZSBkZXRlcm1pbmVkIGJ5IGFuYWx5emluZyB0 aGUgdm9sdW1lIG9mIHRoZSBhdHRhY2suICBUaGUKICAgUmVzcG9uZGVyIE1BWSBzZXQgZGlm ZmVyZW50IGRpZmZpY3VsdHkgbGV2ZWxzIHRvIGRpZmZlcmVudCByZXF1ZXN0cwogICBkZXBl bmRpbmcgb24gdGhlIElQIGFkZHJlc3MgdGhlIHJlcXVlc3QgaGFzIGNvbWUgZnJvbS4KCiAg ICAgICAgICA3LjEuMS4yLiAgU2VsZWN0aW5nIFB1enpsZSBBbGdvcml0aG0KCiAgIFRoZSBQ VVpaTEUgbm90aWZpY2F0aW9uIGFsc28gY29udGFpbnMgaWRlbnRpZmllciBvZiB0aGUgYWxn b3JpdGhtLAogICB0aGF0IG11c3QgYmUgdXNlZCBieSBJbml0aWF0b3IgdG8gY29tcHV0ZSBw dXp6bGUuCgogICBDcnlwdG9ncmFwaGljIGFsZ29yaXRobSBhZ2lsaXR5IGlzIGNvbnNpZGVy ZWQgYW4gaW1wb3J0YW50IGZlYXR1cmUKICAgZm9yIG1vZGVybiBwcm90b2NvbHMgKFtSRkM3 Njk2XSkuICBUaGlzIGZlYXR1cmUgZW5zdXJlcyB0aGF0IHByb3RvY29sCiAgIGRvZXNuJ3Qg cmVseSBvbiBhIHNpbmdsZSBidWlsZC1pbiBzZXQgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0 aG1zLAogICBidXQgaGFzIGEgbWVhbnMgdG8gcmVwbGFjZSBvbmUgc2V0IHdpdGggYW5vdGhl ciBhbmQgbmVnb3RpYXRlIG5ldyBzZXQKICAgd2l0aCB0aGUgcGVlci4gIElLRXYyIGZ1bGx5 IHN1cHBvcnRzIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIGFnaWxpdHkKICAgZm9yIGl0cyBj b3JlIG9wZXJhdGlvbnMuCgogICBUbyBzdXBwb3J0IHRoaXMgZmVhdHVyZSBpbiBjYXNlIG9m IHB1enpsZXMsIHRoZSBhbGdvcml0aG0gdGhhdCBpcwogICB1c2VkIHRvIGNvbXB1dGUgcHV6 emxlIG5lZWRzIHRvIGJlIG5lZ290aWF0ZWQgZHVyaW5nIElLRV9TQV9JTklUCiAgIGV4Y2hh bmdlLiAgVGhlIG5lZ290aWF0aW9uIGlzIHBlcmZvcm1lZCBhcyBmb2xsb3dzLiAgVGhlIGlu aXRpYWwKICAgcmVxdWVzdCBtZXNzYWdlIHNlbnQgYnkgSW5pdGlhdG9yIGNvbnRhaW5zIFNB IHBheWxvYWQgd2l0aCB0aGUgbGlzdAogICBvZiB0cmFuc2Zvcm1zIHRoZSBJbml0aWF0b3Ig c3VwcG9ydHMgYW5kIGlzIHdpbGxpbmcgdG8gdXNlIGluIHRoZSBJS0UKICAgU0EgYmVpbmcg ZXN0YWJsaXNoZWQuICBUaGUgUmVzcG9uZGVyIHBhcnNlcyByZWNlaXZlZCBTQSBwYXlsb2Fk IGFuZAogICBmaW5kcyBtdXR1YWxseSBzdXBwb3J0ZWQgc2V0IG9mIHRyYW5zZm9ybXMgb2Yg dHlwZSBQUkYuICBJdCBzZWxlY3RzCiAgIG1vc3QgcHJlZmVycmVkIHRyYW5zZm9ybSBmcm9t IHRoaXMgc2V0IGFuZCBpbmNsdWRlcyBpdCBpbnRvIHRoZQogICBQVVpaTEUgbm90aWZpY2F0 aW9uLiAgVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCB0aGUgUFJGIHNlbGVjdGVkCiAg IGZvciBwdXp6bGVzIGJlIHRoZSBzYW1lLCBhcyB0aGUgUFJGIHRoYXQgaXMgbmVnb3RpYXRl ZCBsYXRlciBmb3IgdGhlCiAgIHVzZSBpbiBjb3JlIElLRSBTQSBjcnlwdG8gb3BlcmF0aW9u cy4gIElmIHRoZXJlIGFyZSBubyBtdXR1YWxseQogICBzdXBwb3J0ZWQgUFJGcywgdGhlbiBu ZWdvdGlhdGlvbiB3aWxsIGZhaWwgYW55d2F5IGFuZCB0aGVyZSBpcyBubwogICByZWFzb24g dG8gcmV0dXJuIGEgcHV6emxlLiAgSW4gdGhpcyBjYXNlIHRoZSBSZXNwb25kZXIgcmV0dXJu cwogICBOT19QUk9QT1NBTF9DSE9TRU4gbm90aWZpY2F0aW9uLiAgTm90ZSB0aGF0IFBSRiBp cyBhIG1hbmRhdG9yeQogICB0cmFuc2Zvcm0gdHlwZSBmb3IgSUtFIFNBIChzZWUgU2VjdGlv bnMgMy4zLjIgYW5kIDMuMy4zIG9mIFtSRkM3Mjk2XSkKICAgYW5kIGF0IGxlYXN0IG9uZSB0 cmFuc2Zvcm0gb2YgdGhpcyB0eXBlIG11c3QgYWx3YXlzIGJlIHByZXNlbnQgaW4gU0EKICAg cGF5bG9hZCBpbiBJS0VfU0FfSU5JVCByZXF1ZXN0IG1lc3NhZ2UuCgogICAgICAgICAgNy4x LjEuMy4gIEdlbmVyYXRpbmcgQ29va2llCgogICBJZiBSZXNwb25kZXIgc3VwcG9ydHMgcHV6 emxlcyB0aGVuIGNvb2tpZSBzaG91bGQgYmUgY29tcHV0ZWQgaW4gc3VjaAogICBhIG1hbm5l ciwgdGhhdCB0aGUgUmVzcG9uZGVyIGlzIGFibGUgdG8gbGVhcm4gc29tZSBpbXBvcnRhbnQK ICAgaW5mb3JtYXRpb24gZnJvbSB0aGUgc29sZSBjb29raWUsIHdoZW4gaXQgaXMgbGF0ZXIg cmV0dXJuZWQgYmFjayBieQogICBJbml0aWF0b3IuICBJbiBwYXJ0aWN1bGFyIC0gdGhlIFJl c3BvbmRlciBzaG91bGQgYmUgYWJsZSB0byBsZWFybiB0aGUKICAgZm9sbG93aW5nIGluZm9y bWF0aW9uOgoKICAgICAgbyAgV2hldGhlciB0aGUgcHV6emxlIHdhcyBnaXZlbiB0byB0aGUg SW5pdGlhdG9yIG9yIG9ubHkgdGhlCiAgICAgIGNvb2tpZSB3YXMgcmVxdWVzdGVkLgoKICAg ICAgbyAgVGhlIGRpZmZpY3VsdHkgbGV2ZWwgb2YgdGhlIHB1enpsZSBnaXZlbiB0byB0aGUg SW5pdGlhdG9yLgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVt YmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAx NgoKCiAgIG8gIFRoZSBudW1iZXIgb2YgY29uc2VjdXRpdmUgcHV6emxlcyBnaXZlbiB0byB0 aGUgSW5pdGlhdG9yLgoKICAgICAgbyAgVGhlIGFtb3VudCBvZiB0aW1lIHRoZSBJbml0aWF0 b3Igc3BlbnQgdG8gc29sdmUgdGhlIHB1enpsZXMuIAogICAgICBUaGlzIGNhbiBiZSBjYWxj dWxhdGVkIGlmIHRoZSBjb29raWUgaXMgdGltZXN0YW1wZWQuCgogICBUaGlzIGluZm9ybWF0 aW9uIGhlbHBzIHRoZSBSZXNwb25kZXIgdG8gbWFrZSBhIGRlY2lzaW9uIHdoZXRoZXIgdG8K ICAgc2VydmUgdGhpcyByZXF1ZXN0IG9yIGRlbWFuZCBtb3JlIHdvcmsgZnJvbSB0aGUgSW5p dGlhdG9yLgoKICAgT25lIHBvc3NpYmxlIGFwcHJvYWNoIHRvIGdldCB0aGlzIGluZm9ybWF0 aW9uIGlzIHRvIGVuY29kZSBpdCBpbiB0aGUKICAgY29va2llLiAgVGhlIGZvcm1hdCBvZiBz dWNoIGVuY29kaW5nIGlzIGEgbG9jYWwgbWF0dGVyIG9mIFJlc3BvbmRlciwKICAgYXMgdGhl IGNvb2tpZSB3b3VsZCByZW1haW4gYW4gb3BhcXVlIGJsb2IgdG8gdGhlIEluaXRpYXRvci4g IElmIHRoaXMKICAgaW5mb3JtYXRpb24gaXMgZW5jb2RlZCBpbiB0aGUgY29va2llLCB0aGVu IHRoZSBSZXNwb25kZXIgTVVTVCBtYWtlIGl0CiAgIGludGVncml0eSBwcm90ZWN0ZWQsIHNv IHRoYXQgYW55IGludGVuZGVkIG9yIGFjY2lkZW50YWwgYWx0ZXJhdGlvbiBvZgogICB0aGlz IGluZm9ybWF0aW9uIGluIHJldHVybmVkIGNvb2tpZSBpcyBkZXRlY3RhYmxlLiAgU28sIHRo ZSBjb29raWUKICAgd291bGQgYmUgZ2VuZXJhdGVkIGFzOgoKICAgQ29va2llID0gPFZlcnNp b25JRG9mU2VjcmV0PiB8IDxBZGRpdGlvbmFsSW5mbz4gfAogICAgICAgICAgICAgICAgICAg ICBIYXNoKE5pIHwgSVBpIHwgU1BJaSB8IDxBZGRpdGlvbmFsSW5mbz4gfCA8c2VjcmV0PikK CiAgIEFsdGVybmF0aXZlbHksIHRoZSBSZXNwb25kZXIgbWF5IGNvbnRpbnVlIHRvIGdlbmVy YXRlIGNvb2tpZSBhcwogICBzdWdnZXN0ZWQgaW4gU2VjdGlvbiAyLjYgb2YgW1JGQzcyOTZd LCBidXQgYXNzb2NpYXRlIHRoZSBhZGRpdGlvbmFsCiAgIGluZm9ybWF0aW9uLCB0aGF0IHdv dWxkIGJlIHN0b3JlZCBsb2NhbGx5LCB3aXRoIHRoZSBwYXJ0aWN1bGFyCiAgIHZlcnNpb24g b2YgdGhlIHNlY3JldC4gIEluIHRoaXMgY2FzZSB0aGUgUmVzcG9uZGVyIHNob3VsZCBoYXZl CiAgIGRpZmZlcmVudCBzZWNyZXRzIGZvciBldmVyeSBjb21iaW5hdGlvbiBvZiBkaWZmaWN1 bHR5IGxldmVsIGFuZAogICBudW1iZXIgb2YgY29uc2VjdXRpdmUgcHV6emxlcywgYW5kIHNo b3VsZCBjaGFuZ2UgdGhlIHNlY3JldHMKICAgcGVyaW9kaWNhbGx5LCBrZWVwaW5nIGEgZmV3 IHByZXZpb3VzIHZlcnNpb25zLCB0byBiZSBhYmxlIHRvCiAgIGNhbGN1bGF0ZSBob3cgbG9u ZyBhZ28gdGhlIGNvb2tpZSB3YXMgZ2VuZXJhdGVkLgoKICAgVGhlIFJlc3BvbmRlciBtYXkg YWxzbyBjb21iaW5lIHRoZXNlIGFwcHJvYWNoZXMuICBUaGlzIGRvY3VtZW50CiAgIGRvZXNu J3QgbWFuZGF0ZSBob3cgdGhlIFJlc3BvbmRlciBsZWFybnMgdGhpcyBpbmZvcm1hdGlvbiBm cm9tIHRoZQogICBjb29raWUuCgogICAgICAgIDcuMS4yLiAgU29sdmluZyBQdXp6bGUgYW5k IFJldHVybmluZyB0aGUgU29sdXRpb24KCiAgIElmIHRoZSBJbml0aWF0b3IgcmVjZWl2ZXMg YSBwdXp6bGUgYnV0IGl0IGRvZXNuJ3Qgc3VwcG9ydCBwdXp6bGVzLAogICB0aGVuIGl0IHdp bGwgaWdub3JlIHRoZSBQVVpaTEUgbm90aWZpY2F0aW9uIGFzIGFuIHVucmVjb2duaXplZCBz dGF0dXMKICAgbm90aWZpY2F0aW9uIChpbiBhY2NvcmRhbmNlIHRvIFNlY3Rpb24gMy4xMC4x IG9mIFtSRkM3Mjk2XSkuICBUaGUKICAgSW5pdGlhdG9yIGFsc28gTUFZIGlnbm9yZSB0aGUg UFVaWkxFIG5vdGlmaWNhdGlvbiBpZiBpdCBpcyBub3QKICAgd2lsbGluZyB0byBzcGVuZCBy ZXNvdXJjZXMgdG8gc29sdmUgdGhlIHB1enpsZSBvZiB0aGUgcmVxdWVzdGVkCiAgIGRpZmZp Y3VsdHksIGV2ZW4gaWYgaXQgc3VwcG9ydHMgcHV6emxlcy4gIEluIGJvdGggY2FzZXMgdGhl IEluaXRpYXRvcgogICBhY3RzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuNiBvZiBbUkZD NzI5Nl0gLSBpdCByZXN0YXJ0cyB0aGUKICAgcmVxdWVzdCBhbmQgaW5jbHVkZXMgdGhlIHJl Y2VpdmVkIENPT0tJRSBub3RpZmljYXRpb24gaW50byBpdC4gIFRoZQogICBSZXNwb25kZXIg c2hvdWxkIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggdGhlIHNpdHVhdGlvbiB3aGVuIGl0IGp1 c3QKICAgcmVxdWVzdGVkIGEgY29va2llIGZyb20gdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBw dXp6bGUgd2FzIGdpdmVuIHRvCiAgIHRoZSBJbml0aWF0b3IsIGJ1dCB0aGUgSW5pdGlhdG9y IGZvciBzb21lIHJlYXNvbiBpZ25vcmVkIGl0LgoKICAgSWYgdGhlIHJlY2VpdmVkIG1lc3Nh Z2UgY29udGFpbnMgYSBQVVpaTEUgbm90aWZpY2F0aW9uIGFuZCBkb2Vzbid0CiAgIGNvbnRh aW4gYSBDT09LSUUgbm90aWZpY2F0aW9uLCB0aGVuIHRoaXMgbWVzc2FnZSBpcyBtYWxmb3Jt ZWQgYmVjYXVzZQogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1i ZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2 CgoKICAgaXQgcmVxdWVzdHMgdG8gc29sdmUgdGhlIHB1enpsZSwgYnV0IGRvZXNuJ3QgcHJv dmlkZSBlbm91Z2gKICAgaW5mb3JtYXRpb24gdG8gZG8gaXQuICBJbiB0aGlzIGNhc2UgdGhl IEluaXRpYXRvciBTSE9VTEQgcmVzZW5kCiAgIElLRV9TQV9JTklUIHJlcXVlc3QuICBJZiB0 aGlzIHNpdHVhdGlvbiByZXBlYXRzIHNldmVyYWwgdGltZXMsIHRoZW4KICAgaXQgbWVhbnMg dGhhdCBzb21ldGhpbmcgaXMgd3JvbmcgYW5kIHRoZSBJS0UgU0EgY2Fubm90IGJlCiAgIGVz dGFibGlzaGVkLgoKICAgSWYgdGhlIEluaXRpYXRvciBzdXBwb3J0cyBwdXp6bGVzIGFuZCBp cyByZWFkeSB0byBkZWFsIHdpdGggdGhlbSwKICAgdGhlbiBpdCB0cmllcyB0byBzb2x2ZSB0 aGUgZ2l2ZW4gcHV6emxlLiAgQWZ0ZXIgdGhlIHB1enpsZSBpcyBzb2x2ZWQKICAgdGhlIElu aXRpYXRvciByZXN0YXJ0cyB0aGUgcmVxdWVzdCBhbmQgcmV0dXJucyB0aGUgcHV6emxlIHNv bHV0aW9uIGluCiAgIGEgbmV3IHBheWxvYWQgY2FsbGVkIGEgUHV6emxlIFNvbHV0aW9uIHBh eWxvYWQgKGRlbm90ZWQgYXMgUFMsIHNlZQogICBTZWN0aW9uIDkuMikgYWxvbmcgd2l0aCB0 aGUgcmVjZWl2ZWQgQ09PS0lFIG5vdGlmaWNhdGlvbiBiYWNrIHRvIHRoZQogICBSZXNwb25k ZXIuCgogICBIRFIsIE4oQ09PS0lFKSwgW1BTLF0gU0EsIEtFLCBOaSwgW1YrXVtOK10gICAt LT4KCiAgICAgICAgNy4xLjMuICBDb21wdXRpbmcgUHV6emxlCgogICBHZW5lcmFsIHByaW5j aXBhbHMgb2YgY29uc3RydWN0aW5nIHB1enpsZXMgaW4gSUtFdjIgYXJlIGRlc2NyaWJlZCBp bgogICBTZWN0aW9uIDMuICBUaGV5IGNhbiBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6IGdp dmVuIHVucHJlZGljdGFibGUKICAgc3RyaW5nIFMgYW5kIHBzZXVkby1yYW5kb20gZnVuY3Rp b24gUFJGIGZpbmQgTiBkaWZmZXJlbnQga2V5cyBLaQogICAod2hlcmUgaT1bMS4uTl0pIGZv ciB0aGF0IFBSRiBzbyB0aGF0IHRoZSByZXN1bHQgb2YgUFJGKEtpLFMpIGhhcyBhdAogICBs ZWFzdCB0aGUgc3BlY2lmaWVkIG51bWJlciBvZiB0cmFpbGluZyB6ZXJvIGJpdHMuICBUaGlz IHNwZWNpZmljYXRpb24KICAgcmVxdWlyZXMgdGhhdCB0aGUgc29sdXRpb24gdG8gdGhlIHB1 enpsZSBjb250YWlucyA0IGRpZmZlcmVudCBrZXlzCiAgIChpLmUuICBOPTQpLgoKICAgSW4g dGhlIElLRV9TQV9JTklUIGV4Y2hhbmdlIGl0IGlzIHRoZSBjb29raWUgdGhhdCBwbGF5cyB0 aGUgcm9sZSBvZgogICB1bnByZWRpY3RhYmxlIHN0cmluZyBTLiAgSW4gb3RoZXIgd29yZHMs IGluIElLRV9TQV9JTklUIHRoZSB0YXNrIGZvcgogICB0aGUgSUtFIEluaXRpYXRvciBpcyB0 byBmaW5kIHRoZSBmb3VyIGRpZmZlcmVudCwgZXF1YWwtc2l6ZWQga2V5cyBLaQogICBmb3Ig dGhlIGFncmVlZCB1cG9uIFBSRiBzdWNoIHRoYXQgZWFjaCByZXN1bHQgb2YgUFJGKEtpLGNv b2tpZSkgd2hlcmUKICAgaSA9IFsxLi40XSBoYXMgYSBzdWZmaWNpZW50IG51bWJlciBvZiB0 cmFpbGluZyB6ZXJvIGJpdHMuICBPbmx5IHRoZQogICBjb250ZW50IG9mIHRoZSBDT09LSUUg bm90aWZpY2F0aW9uIGlzIHVzZWQgaW4gcHV6emxlIGNhbGN1bGF0aW9uLAogICBpLmUuIHRo ZSBoZWFkZXIgb2YgdGhlIE5vdGlmaWNhdGlvbiBwYXlsb2FkIGlzIG5vdCBpbmNsdWRlZC4K CiAgIE5vdGUsIHRoYXQgcHV6emxlcyBpbiB0aGUgSUtFX0FVVEggZXhjaGFuZ2UgYXJlIGNv bXB1dGVkIGRpZmZlcmVudGx5CiAgIHRoYW4gaW4gdGhlIElLRV9TQV9JTklUX0VYQ0hBTkdF LiAgU2VlIFNlY3Rpb24gNy4yLjMgZm9yIGRldGFpbHMuCgogICAgICAgIDcuMS40LiAgQW5h bHl6aW5nIFJlcGVhdGVkIFJlcXVlc3QKCiAgIFRoZSByZWNlaXZlZCByZXF1ZXN0IG11c3Qg YXQgbGVhc3QgY29udGFpbiBhIENPT0tJRSBub3RpZmljYXRpb24uCiAgIE90aGVyd2lzZSBp dCBpcyBhbiBpbml0aWFsIHJlcXVlc3QgYW5kIGl0IG11c3QgYmUgcHJvY2Vzc2VkIGFjY29y ZGluZwogICB0byBTZWN0aW9uIDcuMS4gIEZpcnN0LCB0aGUgY29va2llIE1VU1QgYmUgY2hl Y2tlZCBmb3IgdmFsaWRpdHkuICBJZgogICB0aGUgY29va2llIGlzIGludmFsaWQsIHRoZW4g dGhlIHJlcXVlc3QgaXMgdHJlYXRlZCBhcyBpbml0aWFsIGFuZCBpcwogICBwcm9jZXNzZWQg YWNjb3JkaW5nIHRvIFNlY3Rpb24gNy4xLiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhIG5l dwogICBjb29raWUgaXMgcmVxdWVzdGVkIGluIHRoaXMgY2FzZS4KCiAgIElmIHRoZSBjb29r aWUgaXMgdmFsaWQgdGhlbiBzb21lIGltcG9ydGFudCBpbmZvcm1hdGlvbiBpcyBsZWFybmVk CiAgIGZyb20gaXQgb3IgZnJvbSBsb2NhbCBzdGF0ZSBiYXNlZCBvbiBpZGVudGlmaWVyIG9m IHRoZSBjb29raWUncwogICBzZWNyZXQgKHNlZSBTZWN0aW9uIDcuMS4xLjMgZm9yIGRldGFp bHMpLiAgVGhpcyBpbmZvcm1hdGlvbiBoZWxwcyB0aGUKIAoKCk5pciAmIFNteXNsb3YgJiBC YXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDE5 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAg ICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIFJlc3BvbmRlciB0byBzb3J0IG91dCBpbmNv bWluZyByZXF1ZXN0cywgZ2l2aW5nIG1vcmUgcHJpb3JpdHkgdG8KICAgdGhvc2Ugb2YgdGhl bSwgd2hpY2ggd2VyZSBjcmVhdGVkIGJ5IHNwZW5kaW5nIG1vcmUgb2YgdGhlIEluaXRpYXRv cidzCiAgIHJlc291cmNlcy4KCiAgIEZpcnN0LCB0aGUgUmVzcG9uZGVyIGRldGVybWluZXMg aWYgaXQgcmVxdWVzdGVkIG9ubHkgYSBjb29raWUsIG9yCiAgIHByZXNlbnRlZCBhIHB1enps ZSB0byB0aGUgSW5pdGlhdG9yLiAgSWYgbm8gcHV6emxlIHdhcyBnaXZlbiwgdGhlbiBpdAog ICBtZWFucyB0aGF0IGF0IHRoZSB0aW1lIHRoZSBSZXNwb25kZXIgcmVxdWVzdGVkIGEgY29v a2llIGl0IGRpZG4ndAogICBkZXRlY3QgdGhlIChEKURvUyBhdHRhY2sgb3IgdGhlIGF0dGFj ayB2b2x1bWUgd2FzIGxvdy4gIEluIHRoaXMgY2FzZQogICB0aGUgcmVjZWl2ZWQgcmVxdWVz dCBtZXNzYWdlIG11c3Qgbm90IGNvbnRhaW4gdGhlIFBTIHBheWxvYWQsIGFuZAogICB0aGlz IHBheWxvYWQgTVVTVCBiZSBpZ25vcmVkIGlmIGZvciBhbnkgcmVhc29uIHRoZSBtZXNzYWdl IGNvbnRhaW5zCiAgIGl0LiAgU2luY2Ugbm8gcHV6emxlIHdhcyBnaXZlbiwgdGhlIFJlc3Bv bmRlciBtYXJrcyB0aGUgcmVxdWVzdCB3aXRoCiAgIHRoZSBsb3dlc3QgcHJpb3JpdHkgc2lu Y2UgdGhlIEluaXRpYXRvciBzcGVudCBsaXR0bGUgcmVzb3VyY2VzCiAgIGNyZWF0aW5nIGl0 LgoKICAgSWYgdGhlIFJlc3BvbmRlciBsZWFybnMgZnJvbSB0aGUgY29va2llIHRoYXQgdGhl IHB1enpsZSB3YXMgZ2l2ZW4gdG8KICAgdGhlIEluaXRpYXRvciwgdGhlbiBpdCBsb29rcyBm b3IgdGhlIFBTIHBheWxvYWQgdG8gZGV0ZXJtaW5lIHdoZXRoZXIKICAgaXRzIHJlcXVlc3Qg dG8gc29sdmUgdGhlIHB1enpsZSB3YXMgaG9ub3JlZCBvciBub3QuICBJZiB0aGUgaW5jb21p bmcKICAgbWVzc2FnZSBkb2Vzbid0IGNvbnRhaW4gYSBQUyBwYXlsb2FkLCB0aGVuIGl0IG1l YW5zIHRoYXQgdGhlCiAgIEluaXRpYXRvciBlaXRoZXIgZG9lc24ndCBzdXBwb3J0IHB1enps ZXMgb3IgZG9lc24ndCB3YW50IHRvIGRlYWwgd2l0aAogICB0aGVtLiAgSW4gZWl0aGVyIGNh c2UgdGhlIHJlcXVlc3QgaXMgbWFya2VkIHdpdGggdGhlIGxvd2VzdCBwcmlvcml0eQogICBz aW5jZSB0aGUgSW5pdGlhdG9yIHNwZW50IGxpdHRsZSByZXNvdXJjZXMgY3JlYXRpbmcgaXQu CgogICBJZiBhIFBTIHBheWxvYWQgaXMgZm91bmQgaW4gdGhlIG1lc3NhZ2UsIHRoZW4gdGhl IFJlc3BvbmRlciBNVVNUCiAgIHZlcmlmeSB0aGUgcHV6emxlIHNvbHV0aW9uIHRoYXQgaXQg Y29udGFpbnMuICBUaGUgc29sdXRpb24gaXMKICAgaW50ZXJwcmV0ZWQgYXMgZm91ciBkaWZm ZXJlbnQga2V5cy4gIFRoZSByZXN1bHQgb2YgdXNpbmcgZWFjaCBvZiB0aGVtCiAgIGluIHRo ZSBQUkYgKGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMS4zKSBtdXN0IGNvbnRhaW4gYXQg bGVhc3QgdGhlCiAgIHJlcXVlc3RlZCBudW1iZXIgb2YgdHJhaWxpbmcgemVybyBiaXRzLiAg VGhlIFJlc3BvbmRlciBNVVNUIGNoZWNrIGFsbAogICB0aGUgZm91ciByZXR1cm5lZCBrZXlz LgoKICAgSWYgYW55IGNoZWNrZWQgcmVzdWx0IGNvbnRhaW5zIGZld2VyIGJpdHMgdGhhbiB3 ZXJlIHJlcXVlc3RlZCwgaXQKICAgbWVhbnMgdGhhdCB0aGUgSW5pdGlhdG9yIHNwZW50IGxl c3MgcmVzb3VyY2VzIHRoYW4gZXhwZWN0ZWQgYnkgdGhlCiAgIFJlc3BvbmRlci4gIFRoaXMg cmVxdWVzdCBpcyBtYXJrZWQgd2l0aCB0aGUgbG93ZXN0IHByaW9yaXR5LgoKICAgSWYgdGhl IEluaXRpYXRvciBwcm92aWRlZCB0aGUgc29sdXRpb24gdG8gdGhlIHB1enpsZSBzYXRpc2Z5 aW5nIHRoZQogICByZXF1ZXN0ZWQgZGlmZmljdWx0eSBsZXZlbCwgb3IgaWYgdGhlIFJlc3Bv bmRlciBkaWRuJ3QgaW5kaWNhdGUgYW55CiAgIHBhcnRpY3VsYXIgZGlmZmljdWx0eSBsZXZl bCAoYnkgc2V0dGluZyBaQkMgdG8gemVybykgYW5kIHRoZQogICBJbml0aWF0b3Igd2FzIGZy ZWUgdG8gc2VsZWN0IGFueSBkaWZmaWN1bHR5IGxldmVsIGl0IGNhbiBhZmZvcmQsIHRoZW4K ICAgdGhlIHByaW9yaXR5IG9mIHRoZSByZXF1ZXN0IGlzIGNhbGN1bGF0ZWQgYmFzZWQgb24g dGhlIGZvbGxvd2luZwogICBjb25zaWRlcmF0aW9uczoKCiAgICAgIG8gIFRoZSBSZXNwb25k ZXIgbXVzdCB0YWtlIHRoZSBzbWFsbGVzdCBudW1iZXIgb2YgdHJhaWxpbmcgemVybwogICAg ICBiaXRzIGFtb25nIHRoZSBjaGVja2VkIHJlc3VsdHMgYW5kIGNvdW50IGl0IGFzIHRoZSBu dW1iZXIgb2YgemVybwogICAgICBiaXRzIHRoZSBJbml0aWF0b3IgZ290LgoKICAgICAgbyAg VGhlIGhpZ2hlciBudW1iZXIgb2YgemVybyBiaXRzIHRoZSBJbml0aWF0b3IgZ290LCB0aGUg aGlnaGVyCiAgICAgIHByaW9yaXR5IGl0cyByZXF1ZXN0IHNob3VsZCByZWNlaXZlLgoKCiAK CgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAg ICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJv dGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBvICBUaGUg bW9yZSBjb25zZWN1dGl2ZSBwdXp6bGVzIHRoZSBJbml0aWF0b3Igc29sdmVkLCB0aGUgaGln aGVyCiAgICAgIHByaW9yaXR5IGl0IHNob3VsZCByZWNlaXZlLgoKICAgICAgbyAgVGhlIG1v cmUgdGltZSB0aGUgSW5pdGlhdG9yIHNwZW50IHNvbHZpbmcgdGhlIHB1enpsZXMsIHRoZQog ICAgICBoaWdoZXIgcHJpb3JpdHkgaXQgc2hvdWxkIHJlY2VpdmUuCgogICBBZnRlciB0aGUg cHJpb3JpdHkgb2YgdGhlIHJlcXVlc3QgaXMgZGV0ZXJtaW5lZCB0aGUgZmluYWwgZGVjaXNp b24KICAgd2hldGhlciB0byBzZXJ2ZSBpdCBvciBub3QgaXMgbWFkZS4KCiAgICAgICAgNy4x LjUuICBNYWtpbmcgRGVjaXNpb24gd2hldGhlciB0byBTZXJ2ZSB0aGUgUmVxdWVzdAoKICAg VGhlIFJlc3BvbmRlciBkZWNpZGVzIHdoYXQgdG8gZG8gd2l0aCB0aGUgcmVxdWVzdCBiYXNl ZCBvbiBpdHMKICAgcHJpb3JpdHkgYW5kIFJlc3BvbmRlcidzIGN1cnJlbnQgbG9hZC4gIFRo ZXJlIGFyZSB0aHJlZSBwb3NzaWJsZQogICBhY3Rpb25zOgoKICAgICAgbyAgQWNjZXB0IHJl cXVlc3QuCgogICAgICBvICBSZWplY3QgcmVxdWVzdC4KCiAgICAgIG8gIERlbWFuZCBtb3Jl IHdvcmsgZnJvbSBJbml0aWF0b3IgYnkgZ2l2aW5nIGl0IGEgbmV3IHB1enpsZS4KCiAgIFRo ZSBSZXNwb25kZXIgU0hPVUxEIGFjY2VwdCBhbiBpbmNvbWluZyByZXF1ZXN0IGlmIGl0cyBw cmlvcml0eSBpcwogICBoaWdoIC0gaXQgbWVhbnMgdGhhdCB0aGUgSW5pdGlhdG9yIHNwZW50 IHF1aXRlIGEgbG90IG9mIHJlc291cmNlcy4KICAgVGhlIFJlc3BvbmRlciBNQVkgYWxzbyBh Y2NlcHQgc29tZSBvZiBsb3ctcHJpb3JpdHkgcmVxdWVzdHMgd2hlcmUgdGhlCiAgIEluaXRp YXRvcnMgZG9uJ3Qgc3VwcG9ydCBwdXp6bGVzLiAgVGhlIHBlcmNlbnRhZ2Ugb2YgYWNjZXB0 ZWQgbGVnYWN5CiAgIHJlcXVlc3RzIGRlcGVuZHMgb24gdGhlIFJlc3BvbmRlcidzIGN1cnJl bnQgbG9hZC4KCiAgIElmIHRoZSBJbml0aWF0b3Igc29sdmVkIHRoZSBwdXp6bGUsIGJ1dCBk aWRuJ3Qgc3BlbmQgbXVjaCByZXNvdXJjZXMKICAgZm9yIGl0ICh0aGUgc2VsZWN0ZWQgcHV6 emxlIGRpZmZpY3VsdHkgbGV2ZWwgYXBwZWFyZWQgdG8gYmUgbG93IGFuZAogICB0aGUgSW5p dGlhdG9yIHNvbHZlZCBpdCBxdWlja2x5KSwgdGhlbiB0aGUgUmVzcG9uZGVyIFNIT1VMRCBn aXZlIGl0CiAgIGFub3RoZXIgcHV6emxlLiAgVGhlIG1vcmUgcHV6emxlcyB0aGUgSW5pdGlh dG9yIHNvbHZlcyB0aGUgaGlnaGVyIGl0cwogICBjaGFuY2VzIGFyZSB0byBiZSBzZXJ2ZWQu CgogICBUaGUgZGV0YWlscyBvZiBob3cgdGhlIFJlc3BvbmRlciBtYWtlcyBhIGRlY2lzaW9u IGZvciBhbnkgcGFydGljdWxhcgogICByZXF1ZXN0LCBhcmUgaW1wbGVtZW50YXRpb24gZGVw ZW5kZW50LiAgVGhlIFJlc3BvbmRlciBjYW4gY29sbGVjdCBhbGwKICAgdGhlIGluY29taW5n IHJlcXVlc3RzIGZvciBzb21lIHNob3J0IHBlcmlvZCBvZiB0aW1lLCBzb3J0IHRoZW0gb3V0 CiAgIGJhc2VkIG9uIHRoZWlyIHByaW9yaXR5LCBjYWxjdWxhdGUgdGhlIG51bWJlciBvZiBh dmFpbGFibGUgbWVtb3J5CiAgIHNsb3RzIGZvciBoYWxmLW9wZW4gSUtFIFNBcyBhbmQgdGhl biBzZXJ2ZSB0aGF0IG51bWJlciBvZiByZXF1ZXN0cwogICBmcm9tIHRoZSBoZWFkIG9mIHRo ZSBzb3J0ZWQgbGlzdC4gIFRoZSByZXN0IG9mIHJlcXVlc3RzIGNhbiBiZSBlaXRoZXIKICAg ZGlzY2FyZGVkIG9yIHJlc3BvbmRlZCB0byB3aXRoIG5ldyBwdXp6bGVzLgoKICAgQWx0ZXJu YXRpdmVseSwgdGhlIFJlc3BvbmRlciBtYXkgZGVjaWRlIHdoZXRoZXIgdG8gYWNjZXB0IGV2 ZXJ5CiAgIGluY29taW5nIHJlcXVlc3Qgd2l0aCBzb21lIGtpbmQgb2YgbG90dGVyeSwgdGFr aW5nIGludG8gYWNjb3VudCBpdHMKICAgcHJpb3JpdHkgYW5kIHRoZSBhdmFpbGFibGUgcmVz b3VyY2VzLgoKCgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVt YmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAx NgoKCjcuMi4gIFB1enpsZXMgaW4gSUtFX0FVVEggRXhjaGFuZ2UKCiAgIE9uY2UgdGhlIElL RV9TQV9JTklUIGV4Y2hhbmdlIGlzIGNvbXBsZXRlZCwgdGhlIFJlc3BvbmRlciBoYXMgY3Jl YXRlZAogICBhIHN0YXRlIGFuZCBpcyB3YWl0aW5nIGZvciB0aGUgZmlyc3QgbWVzc2FnZSBv ZiB0aGUgSUtFX0FVVEggZXhjaGFuZ2UKICAgZnJvbSB0aGUgSW5pdGlhdG9yLiAgQXQgdGhp cyBwb2ludCB0aGUgSW5pdGlhdG9yIGhhcyBhbHJlYWR5IHBhc3NlZAogICByZXR1cm4gcm91 dGFiaWxpdHkgY2hlY2sgYW5kIGhhcyBwcm92ZWQgdGhhdCBpdCBoYXMgcGVyZm9ybWVkIHNv bWUKICAgd29yayB0byBjb21wbGV0ZSBJS0VfU0FfSU5JVCBleGNoYW5nZS4gIEhvd2V2ZXIs IHRoZSBJbml0aWF0b3IgaXMgbm90CiAgIHlldCBhdXRoZW50aWNhdGVkIGFuZCB0aGlzIGZh Y3QgYWxsb3dzIG1hbGljaW91cyBJbml0aWF0b3IgdG8gcGVyZm9ybQogICBhbiBhdHRhY2ss IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuICBVbmxpa2UgRG9TIGF0dGFjayBpbiBJS0VfU0Ff SU5JVAogICBleGNoYW5nZSwgd2hpY2ggaXMgdGFyZ2V0ZWQgb24gdGhlIFJlc3BvbmRlcidz IG1lbW9yeSByZXNvdXJjZXMsIHRoZQogICBnb2FsIG9mIHRoaXMgYXR0YWNrIGlzIHRvIGV4 aGF1c3QgYSBSZXNwb25kZXIncyBDUFUgcG93ZXIuICBUaGUKICAgYXR0YWNrIGlzIHBlcmZv cm1lZCBieSBzZW5kaW5nIHRoZSBmaXJzdCBJS0VfQVVUSCBtZXNzYWdlIGNvbnRhaW5pbmcK ICAgZ2FyYmFnZS4gIFRoaXMgY29zdHMgbm90aGluZyB0byB0aGUgSW5pdGlhdG9yLCBidXQg dGhlIFJlc3BvbmRlciBoYXMKICAgdG8gZG8gcmVsYXRpdmVseSBjb3N0bHkgb3BlcmF0aW9u cyBvZiBjb21wdXRpbmcgdGhlIEQtSCBzaGFyZWQgc2VjcmV0CiAgIGFuZCBkZXJpdmluZyBT S18qIGtleXMgdG8gYmUgYWJsZSB0byB2ZXJpZnkgYXV0aGVudGljaXR5IG9mIHRoZQogICBt ZXNzYWdlLiAgSWYgdGhlIFJlc3BvbmRlciBkb2Vzbid0IGtlZXAgdGhlIGNvbXB1dGVkIGtl eXMgYWZ0ZXIgYW4KICAgdW5zdWNjZXNzZnVsIHZlcmlmaWNhdGlvbiBvZiB0aGUgSUtFX0FV VEggbWVzc2FnZSwgdGhlbiB0aGUgYXR0YWNrCiAgIGNhbiBiZSByZXBlYXRlZCBzZXZlcmFs IHRpbWVzIG9uIHRoZSBzYW1lIElLRSBTQS4KCiAgIFRoZSBSZXNwb25kZXIgY2FuIHVzZSBw dXp6bGVzIHRvIG1ha2UgdGhpcyBhdHRhY2sgbW9yZSBjb3N0bHkgZm9yIHRoZQogICBJbml0 aWF0b3IuICBUaGUgaWRlYSBpcyB0aGF0IHRoZSBSZXNwb25kZXIgaW5jbHVkZXMgYSBwdXp6 bGUgaW4gdGhlCiAgIElLRV9TQV9JTklUIHJlc3BvbnNlIG1lc3NhZ2UgYW5kIHRoZSBJbml0 aWF0b3IgaW5jbHVkZXMgYSBwdXp6bGUKICAgc29sdXRpb24gaW4gdGhlIGZpcnN0IElLRV9B VVRIIHJlcXVlc3QgbWVzc2FnZSBvdXRzaWRlIHRoZSBFbmNyeXB0ZWQKICAgcGF5bG9hZCwg c28gdGhhdCB0aGUgUmVzcG9uZGVyIGlzIGFibGUgdG8gdmVyaWZ5IHB1enpsZSBzb2x1dGlv bgogICBiZWZvcmUgY29tcHV0aW5nIEQtSCBzaGFyZWQgc2VjcmV0LiAgVGhlIGRpZmZpY3Vs dHkgbGV2ZWwgb2YgdGhlCiAgIHB1enpsZSBzaG91bGQgYmUgc2VsZWN0ZWQgc28gdGhhdCB0 aGUgSW5pdGlhdG9yIHdvdWxkIHNwZW5kCiAgIHN1YnN0YW50aWFsbHkgbW9yZSB0aW1lIHRv IHNvbHZlIHRoZSBwdXp6bGUgdGhhbiB0aGUgUmVzcG9uZGVyIHRvCiAgIGNvbXB1dGUgdGhl IHNoYXJlZCBzZWNyZXQuCgogICBUaGUgUmVzcG9uZGVyIHNob3VsZCBjb25zdGFudGx5IG1v bml0b3IgdGhlIGFtb3VudCBvZiB0aGUgaGFsZi1vcGVuCiAgIElLRSBTQSBzdGF0ZXMgdGhh dCByZWNlaXZlIElLRV9BVVRIIG1lc3NhZ2VzIHRoYXQgY2Fubm90IGJlIGRlY3J5cHRlZAog ICBkdWUgdG8gaW50ZWdyaXR5IGNoZWNrIGZhaWx1cmVzLiAgSWYgdGhlIHBlcmNlbnRhZ2Ug b2Ygc3VjaCBzdGF0ZXMgaXMKICAgaGlnaCBhbmQgaXQgdGFrZXMgYW4gZXNzZW50aWFsIGZy YWN0aW9uIG9mIFJlc3BvbmRlcidzIGNvbXB1dGluZwogICBwb3dlciB0byBjYWxjdWxhdGUg a2V5cyBmb3IgdGhlbSwgdGhlbiB0aGUgUmVzcG9uZGVyIG1heSBhc3N1bWUgdGhhdAogICBp dCBpcyB1bmRlciBhdHRhY2sgYW5kIFNIT1VMRCB1c2UgcHV6emxlcyB0byBtYWtlIGl0IGhh cmRlciBmb3IKICAgYXR0YWNrZXJzLgoKICAgICAgICA3LjIuMS4gIFByZXNlbnRpbmcgUHV6 emxlCgogICBUaGUgUmVzcG9uZGVyIHJlcXVlc3RzIHRoZSBJbml0aWF0b3IgdG8gc29sdmUg YSBwdXp6bGUgYnkgaW5jbHVkaW5nCiAgIHRoZSBQVVpaTEUgbm90aWZpY2F0aW9uIGluIHRo ZSBJS0VfU0FfSU5JVCByZXNwb25zZSBtZXNzYWdlLiAgVGhlCiAgIFJlc3BvbmRlciBNVVNU IE5PVCB1c2UgcHV6emxlcyBpbiB0aGUgSUtFX0FVVEggZXhjaGFuZ2UgdW5sZXNzIHRoZQog ICBwdXp6bGUgaGFzIGJlZW4gcHJldmlvdXNseSBwcmVzZW50ZWQgYW5kIHNvbHZlZCBpbiB0 aGUgcHJlY2VkaW5nCiAgIElLRV9TQV9JTklUIGV4Y2hhbmdlLgoKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8LS0gICBIRFIsIFNBLCBLRSwgTnIsIE4oUFVaWkxFKSwgW1YrXVtO K10KCgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwg MjAxNiAgICAgICAgICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBE RG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKNy4y LjEuMS4gIFNlbGVjdGluZyBQdXp6bGUgRGlmZmljdWx0eSBMZXZlbAoKICAgVGhlIGRpZmZp Y3VsdHkgbGV2ZWwgb2YgdGhlIHB1enpsZSBpbiBJS0VfQVVUSCBleGNoYW5nZSBzaG91bGQg YmUKICAgY2hvc2VuIHNvIHRoYXQgdGhlIEluaXRpYXRvciB3b3VsZCBzcGVuZCBtb3JlIHRp bWUgdG8gc29sdmUgdGhlCiAgIHB1enpsZSB0aGFuIHRoZSBSZXNwb25kZXIgdG8gY29tcHV0 ZSB0aGUgRC1IIHNoYXJlZCBzZWNyZXQgYW5kIHRoZQogICBrZXlzLCBuZWVkZWQgdG8gZGVj cnlwdCBhbmQgdmVyaWZ5IHRoZSBJS0VfQVVUSCByZXF1ZXN0IG1lc3NhZ2UuICBPbgogICB0 aGUgb3RoZXIgaGFuZCwgdGhlIGRpZmZpY3VsdHkgbGV2ZWwgc2hvdWxkIG5vdCBiZSB0b28g aGlnaCwKICAgb3RoZXJ3aXNlIHRoZSBsZWdpdGltYXRlIGNsaWVudHMgd291bGQgZXhwZXJp ZW5jZSBhbiBhZGRpdGlvbmFsIGRlbGF5CiAgIHdoaWxlIGVzdGFibGlzaGluZyBJS0UgU0Eu CgogICBOb3RlLCB0aGF0IHNpbmNlIHB1enpsZXMgaW4gdGhlIElLRV9BVVRIIGV4Y2hhbmdl IGFyZSBvbmx5IGFsbG93ZWQgdG8KICAgYmUgdXNlZCBpZiB0aGV5IHdlcmUgdXNlZCBpbiB0 aGUgcHJlY2VkaW5nIElLRV9TQV9JTklUIGV4Y2hhbmdlLCB0aGUKICAgUmVzcG9uZGVyIHdv dWxkIGJlIGFibGUgdG8gZXN0aW1hdGUgdGhlIGNvbXB1dGF0aW9uYWwgcG93ZXIgb2YgdGhl CiAgIEluaXRpYXRvciBhbmQgdG8gc2VsZWN0IHRoZSBkaWZmaWN1bHR5IGxldmVsIGFjY29y ZGluZ2x5LiAgVW5saWtlCiAgIHB1enpsZXMgaW4gSUtFX1NBX0lOSVQsIHRoZSByZXF1ZXN0 ZWQgZGlmZmljdWx0eSBsZXZlbCBmb3IgSUtFX0FVVEgKICAgcHV6emxlcyBNVVNUIE5PVCBi ZSB6ZXJvLiAgSW4gb3RoZXIgd29yZHMsIHRoZSBSZXNwb25kZXIgbXVzdCBhbHdheXMKICAg c2V0IHNwZWNpZmljIGRpZmZpY3VsdHkgbGV2ZWwgYW5kIG11c3Qgbm90IGxldCB0aGUgSW5p dGlhdG9yIHRvCiAgIGNob29zZSBpdCBvbiBpdHMgb3duLgoKICAgICAgICAgIDcuMi4xLjIu ICBTZWxlY3RpbmcgUHV6emxlIEFsZ29yaXRobQoKICAgVGhlIGFsZ29yaXRobSBmb3IgdGhl IHB1enpsZSBpcyBzZWxlY3RlZCBhcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiA3LjEuMS4y LiAgVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQsIHRoYXQgdGhlIGFsZ29yaXRobSBmb3IgdGhl CiAgIHB1enpsZSBpbiB0aGUgSUtFX1NBIElOSVQgZXhjaGFuZ2UgYmUgdGhlIHNhbWUsIGFz IHRoZSBhbGdvcml0aG0gZm9yCiAgIHRoZSBwdXp6bGUgaW4gSUtFX0FVVEggZXhjaGFuZ2Us IGhvd2V2ZXIgaXQgaXMgZXhwZWN0ZWQgdGhhdCBpbiBtb3N0CiAgIGNhc2VzIHRoZXkgd2ls bCBiZSB0aGUgc2FtZS4KCiAgICAgICAgNy4yLjIuICBTb2x2aW5nIFB1enpsZSBhbmQgUmV0 dXJuaW5nIHRoZSBTb2x1dGlvbgoKICAgSWYgdGhlIElLRV9TQV9JTklUIHJlc3BvbnNlIG1l c3NhZ2UgY29udGFpbnMgdGhlIFBVWlpMRSBub3RpZmljYXRpb24KICAgYW5kIHRoZSBJbml0 aWF0b3Igc3VwcG9ydHMgcHV6emxlcywgaXQgTVVTVCBzb2x2ZSB0aGUgcHV6emxlLiAgTm90 ZSwKICAgdGhhdCBwdXp6bGUgY29uc3RydWN0aW9uIGluIHRoZSBJS0VfQVVUSCBleGNoYW5n ZSBkaWZmZXJzIGZyb20gdGhlCiAgIHB1enpsZSBjb25zdHJ1Y3Rpb24gaW4gdGhlIElLRV9T QV9JTklUIGV4Y2hhbmdlIGFuZCBpcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiA3LjIuMy4g IE9uY2UgdGhlIHB1enpsZSBpcyBzb2x2ZWQgdGhlIEluaXRpYXRvciBzZW5kcyB0aGUKICAg SUtFX0FVVEggcmVxdWVzdCBtZXNzYWdlLCBjb250YWluaW5nIHRoZSBQdXp6bGUgU29sdXRp b24gcGF5bG9hZC4KCiAgIEhEUiwgUFMsIFNLIHtJRGksIFtDRVJULF0gW0NFUlRSRVEsXQog ICAgICAgICAgICAgICBbSURyLF0gQVVUSCwgU0EsIFRTaSwgVFNyfSAgIC0tPgoKICAgVGhl IFB1enpsZSBTb2x1dGlvbiBwYXlsb2FkIE1VU1QgYmUgcGxhY2VkIG91dHNpZGUgdGhlIEVu Y3J5cHRlZAogICBwYXlsb2FkLCBzbyB0aGF0IHRoZSBSZXNwb25kZXIgd291bGQgYmUgYWJs ZSB0byB2ZXJpZnkgdGhlIHB1enpsZQogICBiZWZvcmUgY2FsY3VsYXRpbmcgdGhlIEQtSCBz aGFyZWQgc2VjcmV0IGFuZCB0aGUgU0tfKiBrZXlzLgoKICAgSWYgSUtFIEZyYWdtZW50YXRp b24gW1JGQzczODNdIGlzIHVzZWQgaW4gSUtFX0FVVEggZXhjaGFuZ2UsIHRoZW4gdGhlCiAg IFBTIHBheWxvYWQgTVVTVCBiZSBwcmVzZW50IG9ubHkgaW4gdGhlIGZpcnN0IElLRSBGcmFn bWVudCBtZXNzYWdlLCBpbgogICBhY2NvcmRhbmNlIHdpdGggdGhlIFNlY3Rpb24gMi41LjMg b2YgW1JGQzczODNdLiAgTm90ZSwgdGhhdAogICBjYWxjdWxhdGlvbiBvZiB0aGUgcHV6emxl IGluIHRoZSBJS0VfQVVUSCBleGNoYW5nZSBkb2Vzbid0IGRlcGVuZCBvbgogICB0aGUgY29u dGVudCBvZiB0aGUgSUtFX0FVVEggbWVzc2FnZSAoc2VlIFNlY3Rpb24gNy4yLjMpLiAgVGh1 cyB0aGUKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDks IDIwMTYgICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg RERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAg IEluaXRpYXRvciBoYXMgdG8gc29sdmUgdGhlIHB1enpsZSBvbmx5IG9uY2UgYW5kIHRoZSBz b2x1dGlvbiBpcyB2YWxpZAogICBmb3IgYm90aCB1bmZyYWdtZW50ZWQgYW5kIGZyYWdtZW50 ZWQgSUtFIG1lc3NhZ2VzLgoKICAgICAgICA3LjIuMy4gIENvbXB1dGluZyBQdXp6bGUKCiAg IFRoZSBwdXp6bGVzIGluIHRoZSBJS0VfQVVUSCBleGNoYW5nZSBhcmUgY29tcHV0ZWQgZGlm ZmVyZW50bHkgdGhhbiBpbgogICB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UgKHNlZSBTZWN0 aW9uIDcuMS4zKS4gIFRoZSBnZW5lcmFsIHByaW5jaXBsZQogICBpcyB0aGUgc2FtZTsgdGhl IGRpZmZlcmVuY2UgaXMgaW4gdGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgc3RyaW5nIFMuCiAg IFVubGlrZSB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UsIHdoZXJlIFMgaXMgdGhlIGNvb2tp ZSwgaW4gdGhlCiAgIElLRV9BVVRIIGV4Y2hhbmdlIFMgaXMgYSBjb25jYXRlbmF0aW9uIG9m IE5yIGFuZCBTUElyLiAgSW4gb3RoZXIKICAgd29yZHMsIHRoZSB0YXNrIGZvciBJS0UgSW5p dGlhdG9yIGlzIHRvIGZpbmQgdGhlIGZvdXIgZGlmZmVyZW50IGtleXMKICAgS2kgZm9yIHRo ZSBhZ3JlZWQgdXBvbiBQUkYgc3VjaCB0aGF0IGVhY2ggcmVzdWx0IG9mIFBSRihLaSxOciB8 IFNQSXIpCiAgIHdoZXJlIGk9WzEuLjRdIGhhcyBhIHN1ZmZpY2llbnQgbnVtYmVyIG9mIHRy YWlsaW5nIHplcm8gYml0cy4gIE5yIGlzCiAgIGEgbm9uY2UgdXNlZCBieSB0aGUgUmVzcG9u ZGVyIGluIElLRV9TQV9JTklUIGV4Y2hhbmdlLCBzdHJpcHBlZCBvZgogICBhbnkgaGVhZGVy cy4gIFNQSXIgaXMgSUtFIFJlc3BvbmRlcidzIFNQSSBmcm9tIHRoZSBJS0UgaGVhZGVyIG9m IHRoZQogICBTQSBiZWluZyBlc3RhYmxpc2hlZC4KCiAgICAgICAgNy4yLjQuICBSZWNlaXZp bmcgUHV6emxlIFNvbHV0aW9uCgogICBJZiB0aGUgUmVzcG9uZGVyIHJlcXVlc3RlZCB0aGUg SW5pdGlhdG9yIHRvIHNvbHZlIGEgcHV6emxlIGluIHRoZQogICBJS0VfQVVUSCBleGNoYW5n ZSwgdGhlbiBpdCBNVVNUIHNpbGVudGx5IGRpc2NhcmQgYWxsIHRoZSBJS0VfQVVUSAogICBy ZXF1ZXN0IG1lc3NhZ2VzIHdpdGhvdXQgdGhlIFB1enpsZSBTb2x1dGlvbiBwYXlsb2FkLgoK ICAgT25jZSB0aGUgbWVzc2FnZSBjb250YWluaW5nIGEgc29sdXRpb24gdG8gdGhlIHB1enps ZSBpcyByZWNlaXZlZCwgdGhlCiAgIFJlc3BvbmRlciBNVVNUIHZlcmlmeSB0aGUgc29sdXRp b24gYmVmb3JlIHBlcmZvcm1pbmcgY29tcHV0YXRpb25sbHkKICAgaW50ZW5zaXZlIG9wZXJh dGlvbnMgaS5lLiBjb21wdXRpbmcgdGhlIEQtSCBzaGFyZWQgc2VjcmV0IGFuZCB0aGUKICAg U0tfKiBrZXlzLiAgVGhlIFJlc3BvbmRlciBNVVNUIHZlcmlmeSBhbGwgdGhlIGZvdXIgcmV0 dXJuZWQga2V5cy4KCiAgIFRoZSBSZXNwb25kZXIgTVVTVCBzaWxlbnRseSBkaXNjYXJkIHRo ZSByZWNlaXZlZCBtZXNzYWdlIGlmIGFueQogICBjaGVja2VkIHZlcmlmaWNhdGlvbiByZXN1 bHQgaXMgbm90IGNvcnJlY3QgKGNvbnRhaW5zIGluc3VmZmljaWVudAogICBudW1iZXIgb2Yg dHJhaWxpbmcgemVybyBiaXRzKS4gIElmIHRoZSBSZXNwb25kZXIgc3VjY2Vzc2Z1bGx5CiAg IHZlcmlmaWVzIHRoZSBwdXp6bGUgYW5kIGNhbGN1bGF0ZXMgdGhlIFNLXyoga2V5LCBidXQg dGhlIG1lc3NhZ2UKICAgYXV0aGVudGljaXR5IGNoZWNrIGZhaWxzLCB0aGVuIGl0IFNIT1VM RCBzYXZlIHRoZSBjYWxjdWxhdGVkIGtleXMgaW4KICAgdGhlIElLRSBTQSBzdGF0ZSB3aGls ZSB3YWl0aW5nIGZvciB0aGUgcmV0cmFuc21pc3Npb25zIGZyb20gdGhlCiAgIEluaXRpYXRv ci4gIEluIHRoaXMgY2FzZSB0aGUgUmVzcG9uZGVyIG1heSBza2lwIHZlcmlmaWNhdGlvbiBv ZiB0aGUKICAgcHV6emxlIHNvbHV0aW9uIGFuZCBpZ25vcmUgdGhlIFB1enpsZSBTb2x1dGlv biBwYXlsb2FkIGluIHRoZQogICByZXRyYW5zbWl0dGVkIG1lc3NhZ2VzLgoKICAgSWYgdGhl IEluaXRpYXRvciB1c2VzIElLRSBGcmFnbWVudGF0aW9uLCB0aGVuIGl0IGlzIHBvc3NpYmxl LCB0aGF0CiAgIGR1ZSB0byBwYWNrZXQgbG9zcyBhbmQvb3IgcmVvcmRlcmluZyB0aGUgUmVz cG9uZGVyIGNvdWxkIHJlY2VpdmUgbm9uLQogICBmaXJzdCBJS0UgRnJhZ21lbnQgbWVzc2Fn ZXMgYmVmb3JlIHJlY2VpdmluZyB0aGUgZmlyc3Qgb25lLAogICBjb250YWluaW5nIHRoZSBQ UyBwYXlsb2FkLiAgSW4gdGhpcyBjYXNlIHRoZSBSZXNwb25kZXIgTUFZIGNob29zZSB0bwog ICBrZWVwIHRoZSByZWNlaXZlZCBmcmFnbWVudHMgdW50aWwgdGhlIGZpcnN0IGZyYWdtZW50 IGNvbnRhaW5pbmcgdGhlCiAgIHNvbHV0aW9uIHRvIHRoZSBwdXp6bGUgaXMgcmVjZWl2ZWQu ICBIb3dldmVyLCBpbiB0aGlzIGNhc2UgdGhlCiAgIFJlc3BvbmRlciBTSE9VTEQgTk9UIHRy eSB0byB2ZXJpZnkgYXV0aGVudGljaXR5IG9mIHRoZSBrZXB0IGZyYWdtZW50cwogICB1bnRp bCB0aGUgZmlyc3QgZnJhZ21lbnQgd2l0aCB0aGUgUFMgcGF5bG9hZCBpcyByZWNlaXZlZCBh bmQgdGhlCiAgIHNvbHV0aW9uIHRvIHRoZSBwdXp6bGUgaXMgdmVyaWZpZWQuICBBZnRlciBz dWNjZXNzZnVsIHZlcmlmaWNhdGlvbiBvZgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0 dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDI0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAg ICAgICAgTWFyY2ggMjAxNgoKCiAgIHRoZSBwdXp6bGUgdGhlIFJlc3BvbmRlciBjb3VsZCBj YWxjdWxhdGUgdGhlIFNLXyoga2V5IGFuZCB2ZXJpZnkKICAgYXV0aGVudGljaXR5IG9mIHRo ZSBjb2xsZWN0ZWQgZnJhZ21lbnRzLgoKICAgIDguICBEb1MgUHJvdGVjdGlvbiBhZnRlciBJ S0UgU0EgaXMgY3JlYXRlZAoKICAgT25jZSBJS0UgU0EgaXMgY3JlYXRlZCB0aGVyZSBpcyB1 c3VhbGx5IG5vdCBtdWNoIHRyYWZmaWMgb3ZlciBpdC4gIEluCiAgIG1vc3QgY2FzZXMgdGhp cyB0cmFmZmljIGNvbnNpc3RzIG9mIGV4Y2hhbmdlcyBhaW1lZCB0byBjcmVhdGUKICAgYWRk aXRpb25hbCBDaGlsZCBTQXMsIHJla2V5LCBvciBkZWxldGUgdGhlbSBhbmQgY2hlY2sgdGhl IGxpdmVuZXNzIG9mCiAgIHRoZSBwZWVyLiAgV2l0aCBhIHR5cGljYWwgc2V0dXAgYW5kIHR5 cGljYWwgQ2hpbGQgU0EgbGlmZXRpbWVzLCB0aGVyZQogICBhcmUgdHlwaWNhbGx5IG5vIG1v cmUgdGhhbiBhIGZldyBzdWNoIGV4Y2hhbmdlcywgb2Z0ZW4gbGVzcy4gIFNvbWUgb2YKICAg dGhlc2UgZXhjaGFuZ2VzIHJlcXVpcmUgcmVsYXRpdmVseSBsaXR0bGUgcmVzb3VyY2VzIChs aWtlIGxpdmVuZXNzCiAgIGNoZWNrKSwgd2hpbGUgb3RoZXJzIG1heSBiZSByZXNvdXJjZSBj b25zdW1pbmcgKGxpa2UgY3JlYXRpbmcgb3IKICAgcmVrZXlpbmcgQ2hpbGQgU0Egd2l0aCBE LUggZXhjaGFuZ2UpLgoKICAgU2luY2UgYW55IGVuZHBvaW50IGNhbiBpbml0aWF0ZSBhIG5l dyBleGNoYW5nZSwgdGhlcmUgaXMgYQogICBwb3NzaWJpbGl0eSB0aGF0IGEgcGVlciB3b3Vs ZCBpbml0aWF0ZSB0b28gbWFueSBleGNoYW5nZXMgdGhhdCBjb3VsZAogICBleGhhdXN0IGhv c3QgcmVzb3VyY2VzLiAgRm9yIGV4YW1wbGUsIHRoZSBwZWVyIGNhbiBwZXJmb3JtIGVuZGxl c3MKICAgY29udGludW91cyBDaGlsZCBTQSByZWtleWluZyBvciBjcmVhdGUgb3ZlcndoZWxt aW5nIG51bWJlciBvZiBDaGlsZAogICBTQXMgd2l0aCB0aGUgc2FtZSBUcmFmZmljIFNlbGVj dG9ycyBldGMuICBTdWNoIGJlaGF2aW9yIG1heSBiZSBjYXVzZWQKICAgYnkgYnVnZ3kgaW1w bGVtZW50YXRpb24sIG1pc2NvbmZpZ3VyYXRpb24gb3IgYmUgaW50ZW50aW9uYWwuICBUaGUK ICAgbGF0dGVyIGJlY29tZXMgbW9yZSBvZiBhIHJlYWwgdGhyZWF0IGlmIHRoZSBwZWVyIHVz ZXMgTlVMTAogICBBdXRoZW50aWNhdGlvbiwgZGVzY3JpYmVkIGluIFtSRkM3NjE5XS4gIElu IHRoaXMgY2FzZSB0aGUgcGVlcgogICByZW1haW5zIGFub255bW91cywgYWxsb3dpbmcgaXQg dG8gZXNjYXBlIGFueSByZXNwb25zaWJpbGl0eSBmb3IgaXRzCiAgIGFjdGlvbnMuCgogICBU aGUgZm9sbG93aW5nIHJlY29tbWVuZGF0aW9ucyBmb3IgZGVmZW5zZSBhZ2FpbnN0IHBvc3Np YmxlIERvUwogICBhdHRhY2tzIGFmdGVyIElLRSBTQSBpcyBlc3RhYmxpc2hlZCBhcmUgbW9z dGx5IGludGVuZGVkIGZvcgogICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhbGxvdyB1bmF1dGhl bnRpY2F0ZWQgSUtFIHNlc3Npb25zOyBob3dldmVyLAogICB0aGV5IG1heSBhbHNvIGJlIHVz ZWZ1bCBpbiBvdGhlciBjYXNlcy4KCiAgICAgIG8gIElmIHRoZSBJS0V2MiB3aW5kb3cgc2l6 ZSBpcyBncmVhdGVyIHRoYW4gb25lLCB0aGVuIHRoZSBwZWVyCiAgICAgIGNvdWxkIGluaXRp YXRlIG11bHRpcGxlIHNpbXVsdGFuZW91cyBleGNoYW5nZXMgdGhhdCBjb3VsZCBpbmNyZWFz ZQogICAgICBob3N0IHJlc291cmNlIGNvbnN1bXB0aW9uLiAgU2luY2UgY3VycmVudGx5IHRo ZXJlIGlzIG5vIHdheSBpbgogICAgICBJS0V2MiB0byBkZWNyZWFzZSB3aW5kb3cgc2l6ZSBv bmNlIGl0IHdhcyBpbmNyZWFzZWQgKHNlZQogICAgICBTZWN0aW9uIDIuMyBvZiBbUkZDNzI5 Nl0pLCB0aGUgd2luZG93IHNpemUgY2Fubm90IGJlIGR5bmFtaWNhbGx5CiAgICAgIGFkanVz dGVkIGRlcGVuZGluZyBvbiB0aGUgbG9hZC4gIEZvciB0aGF0IHJlYXNvbiwgaXQgaXMgTk9U CiAgICAgIFJFQ09NTUVOREVEIHRvIGV2ZXIgaW5jcmVhc2UgdGhlIElLRXYyIHdpbmRvdyBz aXplIGFib3ZlIGl0cwogICAgICBkZWZhdWx0IHZhbHVlIG9mIG9uZSBpZiB0aGUgcGVlciB1 c2VzIE5VTEwgQXV0aGVudGljYXRpb24uCgogICAgICBvICBJZiB0aGUgcGVlciBpbml0aWF0 ZXMgcmVxdWVzdHMgdG8gcmVrZXkgSUtFIFNBIG9yIENoaWxkIFNBIHRvbwogICAgICBvZnRl biwgaW1wbGVtZW50YXRpb25zIGNhbiByZXNwb25kIHRvIHNvbWUgb2YgdGhlc2UgcmVxdWVz dHMgd2l0aAogICAgICB0aGUgVEVNUE9SQVJZX0ZBSUxVUkUgbm90aWZpY2F0aW9uLCBpbmRp Y2F0aW5nIHRoYXQgdGhlIHJlcXVlc3QKICAgICAgc2hvdWxkIGJlIHJldHJpZWQgYWZ0ZXIg c29tZSBwZXJpb2Qgb2YgdGltZS4KCiAgICAgIG8gIElmIHRoZSBwZWVyIGNyZWF0ZXMgdG9v IG1hbnkgQ2hpbGQgU0Egd2l0aCB0aGUgc2FtZSBvcgogICAgICBvdmVybGFwcGluZyBUcmFm ZmljIFNlbGVjdG9ycywgaW1wbGVtZW50YXRpb25zIGNhbiByZXNwb25kIHdpdGgKICAgICAg dGhlIE5PX0FERElUSU9OQUxfU0FTIG5vdGlmaWNhdGlvbi4KCiAKCgpOaXIgJiBTbXlzbG92 ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFn ZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtF djIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBvICBJZiB0aGUgcGVlciBpbml0aWF0 ZXMgdG9vIG1hbnkgZXhjaGFuZ2VzIG9mIGFueSBraW5kLAogICAgICBpbXBsZW1lbnRhdGlv bnMgY2FuIGludHJvZHVjZSBhbiBhcnRpZmljaWFsIGRlbGF5IGJlZm9yZQogICAgICByZXNw b25kaW5nIHRvIHJlcXVlc3QgbWVzc2FnZXMuICBUaGlzIGRlbGF5IHdvdWxkIGRlY3JlYXNl IHRoZQogICAgICByYXRlIHRoZSBpbXBsZW1lbnRhdGlvbiBuZWVkIHRvIHByb2Nlc3MgcmVx dWVzdHMgZnJvbSBhbnkKICAgICAgcGFydGljdWxhciBwZWVyLCBtYWtpbmcgaXQgcG9zc2li bGUgdG8gcHJvY2VzcyByZXF1ZXN0cyBmcm9tIHRoZQogICAgICBvdGhlcnMuICBUaGUgZGVs YXkgc2hvdWxkIG5vdCBiZSB0b28gbG9uZyB0byBhdm9pZCBjYXVzaW5nIHRoZSBJS0UKICAg ICAgU0EgdG8gYmUgZGVsZXRlZCBvbiB0aGUgb3RoZXIgZW5kIGR1ZSB0byB0aW1lb3V0LiAg SXQgaXMgYmVsaWV2ZWQKICAgICAgdGhhdCBhIGZldyBzZWNvbmRzIGlzIGVub3VnaC4gIE5v dGUsIHRoYXQgaWYgdGhlIFJlc3BvbmRlcgogICAgICByZWNlaXZlcyByZXRyYW5zbWlzc2lv bnMgb2YgdGhlIHJlcXVlc3QgbWVzc2FnZSBkdXJpbmcgdGhlIGRlbGF5CiAgICAgIHBlcmlv ZCwgdGhlIHJldHJhbnNtaXR0ZWQgbWVzc2FnZXMgc2hvdWxkIGJlIHNpbGVudGx5IGRpc2Nh cmRlZC4KCiAgICAgIG8gIElmIHRoZXNlIGNvdW50ZXItbWVhc3VyZXMgYXJlIGluZWZmaWNp ZW50LCBpbXBsZW1lbnRhdGlvbnMgY2FuCiAgICAgIGRlbGV0ZSB0aGUgSUtFIFNBIHdpdGgg YW4gb2ZmZW5kaW5nIHBlZXIgYnkgc2VuZGluZyBEZWxldGUKICAgICAgUGF5bG9hZC4KCiAg ICA5LiAgUGF5bG9hZCBGb3JtYXRzCgogICAgICA5LjEuICBQVVpaTEUgTm90aWZpY2F0aW9u CgogICBUaGUgUFVaWkxFIG5vdGlmaWNhdGlvbiBpcyB1c2VkIGJ5IHRoZSBJS0UgUmVzcG9u ZGVyIHRvIGluZm9ybSB0aGUKICAgSW5pdGlhdG9yIGFib3V0IHRoZSBuZWNlc3NpdHkgdG8g c29sdmUgdGhlIHB1enpsZS4gIEl0IGNvbnRhaW5zIHRoZQogICBkaWZmaWN1bHR5IGxldmVs IG9mIHRoZSBwdXp6bGUgYW5kIHRoZSBQUkYgdGhlIEluaXRpYXRvciBzaG91bGQgdXNlLgoK ICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8IE5leHQgUGF5 bG9hZCAgfEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAg fAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICB8UHJvdG9jb2wgSUQoPTApfCBTUEkgU2l6ZSAoPTApIHwg ICAgICBOb3RpZnkgTWVzc2FnZSBUeXBlICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAg ICAgICAgICAgICBQUkYgICAgICAgICAgICAgIHwgIERpZmZpY3VsdHkgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgIG8g IFByb3RvY29sIElEICgxIG9jdGV0KSAtLSBNVVNUIGJlIDAuCgogICAgICBvICBTUEkgU2l6 ZSAoMSBvY3RldCkgLSBNVVNUIGJlIDAsIG1lYW5pbmcgbm8gU2VjdXJpdHkgUGFyYW1ldGVy CiAgICAgIEluZGV4IChTUEkpIGlzIHByZXNlbnQuCgogICAgICBvICBOb3RpZnkgTWVzc2Fn ZSBUeXBlICgyIG9jdGV0cykgLS0gTVVTVCBiZSA8VEJBIGJ5IElBTkE+LCB0aGUKICAgICAg dmFsdWUgYXNzaWduZWQgZm9yIHRoZSBQVVpaTEUgbm90aWZpY2F0aW9uLgoKICAgICAgbyAg UFJGICgyIG9jdGV0cykgLS0gVHJhbnNmb3JtIElEIG9mIHRoZSBQUkYgYWxnb3JpdGhtIHRo YXQgbXVzdAogICAgICBiZSB1c2VkIHRvIHNvbHZlIHRoZSBwdXp6bGUuICBSZWFkZXJzIHNo b3VsZCByZWZlciB0byB0aGUgc2VjdGlvbgogICAgICAiVHJhbnNmb3JtIFR5cGUgMiAtIFBz ZXVkby1SYW5kb20gRnVuY3Rpb24gVHJhbnNmb3JtIElEcyIgaW4KICAgICAgW0lLRVYyLUlB TkFdIGZvciB0aGUgbGlzdCBvZiBwb3NzaWJsZSB2YWx1ZXMuCgogICAgICBvICBEaWZmaWN1 bHR5ICgxIG9jdGV0KSAtLSBEaWZmaWN1bHR5IExldmVsIG9mIHRoZSBwdXp6bGUuIAogICAg ICBTcGVjaWZpZXMgbWluaW11bSBudW1iZXIgb2YgdHJhaWxpbmcgemVybyBiaXRzIChaQkMp LCB0aGF0IGVhY2ggb2YKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2Vw dGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDI2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2gg MjAxNgoKCiAgICAgIHRoZQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJl ciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYK CgogICAgICByZXN1bHRzIG9mIFBSRiBtdXN0IGNvbnRhaW4uICBWYWx1ZSAwIG1lYW5zIHRo YXQgdGhlIFJlc3BvbmRlcgogICAgICBkb2Vzbid0IHJlcXVlc3QgYW55IHNwZWNpZmljIGRp ZmZpY3VsdHkgbGV2ZWwgYW5kIHRoZSBJbml0aWF0b3IgaXMKICAgICAgZnJlZSB0byBzZWxl Y3QgYXBwcm9wcmlhdGUgZGlmZmljdWx0eSBsZXZlbCBvbiBpdHMgb3duIChzZWUKICAgICAg U2VjdGlvbiA3LjEuMS4xIGZvciBkZXRhaWxzKS4KCiAgIFRoaXMgbm90aWZpY2F0aW9uIGNv bnRhaW5zIG5vIGRhdGEuCgogICAgICA5LjIuICBQdXp6bGUgU29sdXRpb24gUGF5bG9hZAoK ICAgVGhlIHNvbHV0aW9uIHRvIHRoZSBwdXp6bGUgaXMgcmV0dXJuZWQgYmFjayB0byB0aGUg UmVzcG9uZGVyIGluIGEKICAgZGVkaWNhdGVkIHBheWxvYWQsIGNhbGxlZCB0aGUgUHV6emxl IFNvbHV0aW9uIHBheWxvYWQgYW5kIGRlbm90ZWQgYXMKICAgUFMgaW4gdGhpcyBkb2N1bWVu dC4KCiAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAg ICAgICAgICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCBOZXh0 IFBheWxvYWQgIHxDfCAgUkVTRVJWRUQgICB8ICAgICAgICAgUGF5bG9hZCBMZW5ndGggICAg ICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgfiAgICAgICAgICAgICAg ICAgICAgIFB1enpsZSBTb2x1dGlvbiBEYXRhICAgICAgICAgICAgICAgICAgICAgIH4KICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgIG8gIFB1enpsZSBTb2x1dGlvbiBE YXRhICh2YXJpYWJsZSBsZW5ndGgpIC0tIENvbnRhaW5zIHRoZSBzb2x1dGlvbgogICAgICB0 byB0aGUgcHV6emxlIC0gZm91ciBkaWZmZXJlbnQga2V5cyBmb3IgdGhlIHNlbGVjdGVkIFBS Ri4gIFRoaXMKICAgICAgZmllbGQgTVVTVCBOT1QgYmUgZW1wdHkuICBBbGwgdGhlIGtleXMg TVVTVCBoYXZlIHRoZSBzYW1lIHNpemUsCiAgICAgIHRoZXJlZm9yZSB0aGUgc2l6ZSBvZiB0 aGlzIGZpZWxkIGlzIGFsd2F5cyBhIG11dGlwbGUgb2YgNCBieXRlcy4KICAgICAgSWYgdGhl IHNlbGVjdGVkIFBSRiBhY2NlcHRzIG9ubHkgZml4ZWQtc2l6ZSBrZXlzLCB0aGVuIHRoZSBz aXplIG9mCiAgICAgIGVhY2gga2V5IE1VU1QgYmUgb2YgdGhhdCBmaXhlZCBzaXplLiAgSWYg dGhlIFBSRiBhZ3JlZWQgdXBvbgogICAgICBhY2NlcHRzIGtleXMgb2YgYW55IHNpemUsIHRo ZW4gdGhlbiB0aGUgc2l6ZSBvZiBlYWNoIGtleSBNVVNUIGJlCiAgICAgIGJldHdlZW4gMSBv Y3RldCBhbmQgdGhlIHByZWZlcnJlZCBrZXkgbGVuZ3RoIG9mIHRoZSBQUkYKICAgICAgKGlu Y2x1c2l2ZSkuICBJdCBpcyBleHBlY3RlZCB0aGF0IGluIG1vc3QgY2FzZXMgdGhlIGtleXMg d2lsbCBiZSA0CiAgICAgIChvciBldmVuIGxlc3MpIG9jdGV0cyBpbiBsZW5ndGgsIGhvd2V2 ZXIgaXQgZGVwZW5kcyBvbiBwdXp6bGUKICAgICAgZGlmZmljdWx0eSBhbmQgb24gdGhlIElu aXRpYXRvcidzIHN0cmF0ZWd5IHRvIGZpbmQgc29sdXRpb25zLCBhbmQKICAgICAgdGh1cyB0 aGUgc2l6ZSBpcyBub3QgbWFuZGF0ZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlCiAg ICAgIFJlc3BvbmRlciBkZXRlcm1pbmVzIHRoZSBzaXplIG9mIGVhY2gga2V5IGJ5IGRpdmlk aW5nIHRoZSBzaXplIG9mCiAgICAgIHRoZSBQdXp6bGUgU29sdXRpb24gRGF0YSBieSA0ICh0 aGUgbnVtYmVyIG9mIGtleXMpLiAgTm90ZSB0aGF0IHRoZQogICAgICBzaXplIG9mIFB1enps ZSBTb2x1dGlvbiBEYXRhIGlzIHRoZSBzaXplIG9mIFBheWxvYWQgKGFzIGluZGljYXRlZAog ICAgICBpbiBQYXlsb2FkIExlbmd0aCBmaWVsZCkgbWludXMgNCAtIHRoZSBzaXplIG9mIFBh eWxvYWQgSGVhZGVyLgoKICAgVGhlIHBheWxvYWQgdHlwZSBmb3IgdGhlIFB1enpsZSBTb2x1 dGlvbiBwYXlsb2FkIGlzIDxUQkEgYnkgSUFOQT4uCgogICAgIDEwLiAgT3BlcmF0aW9uYWwg Q29uc2lkZXJhdGlvbnMKCiAgIFRoZSBkaWZmaWN1bHR5IGxldmVsIHNob3VsZCBiZSBzZXQg YnkgYmFsYW5jaW5nIHRoZSByZXF1aXJlbWVudCB0bwogICBtaW5pbWl6ZSB0aGUgbGF0ZW5j eSBmb3IgbGVnaXRpbWF0ZSBJbml0aWF0b3JzIGFuZCBtYWtpbmcgdGhpbmdzCiAgIGRpZmZp Y3VsdCBmb3IgYXR0YWNrZXJzLiAgQSBnb29kIHJ1bGUgb2YgdGh1bWIgaXMgZm9yIHRha2lu ZyBhYm91dCAxCiAgIHNlY29uZCB0byBzb2x2ZSB0aGUgcHV6emxlLiAgQSB0eXBpY2FsIElu aXRpYXRvciBvciBib3QtbmV0IG1lbWJlciBpbgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRs ZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAg ICAgICAgICBNYXJjaCAyMDE2CgoKICAgMjAxNCBjYW4gcGVyZm9ybSBzbGlnaHRseSBsZXNz IHRoYW4gYSBtaWxsaW9uIGhhc2hlcyBwZXIgc2Vjb25kIHBlcgogICBjb3JlLCBzbyBzZXR0 aW5nIHRoZSBkaWZmaWN1bHR5IGxldmVsIHRvIG49MjAgaXMgYSBnb29kIGNvbXByb21pc2Uu CiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IG1vYmlsZSBJbml0aWF0b3JzLCBlc3BlY2lh bGx5IHBob25lcyBhcmUKICAgY29uc2lkZXJhYmx5IHdlYWtlciB0aGFuIHRoYXQuICBJbXBs ZW1lbnRhdGlvbnMgc2hvdWxkIGFsbG93CiAgIGFkbWluaXN0cmF0b3JzIHRvIHNldCB0aGUg ZGlmZmljdWx0eSBsZXZlbCwgYW5kL29yIGJlIGFibGUgdG8gc2V0IHRoZQogICBkaWZmaWN1 bHR5IGxldmVsIGR5bmFtaWNhbGx5IGluIHJlc3BvbnNlIHRvIGxvYWQuCgogICBJbml0aWF0 b3JzIHNob3VsZCBzZXQgYSBtYXhpbXVtIGRpZmZpY3VsdHkgbGV2ZWwgYmV5b25kIHdoaWNo IHRoZXkKICAgd29uJ3QgdHJ5IHRvIHNvbHZlIHRoZSBwdXp6bGUgYW5kIGxvZyBvciBkaXNw bGF5IGEgZmFpbHVyZSBtZXNzYWdlIHRvCiAgIHRoZSBhZG1pbmlzdHJhdG9yIG9yIHVzZXIu CgogICAgIDExLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFdoZW4gc2VsZWN0aW5n IHBhcmFtZXRlcnMgZm9yIHRoZSBwdXp6bGVzLCBpbiBwYXJ0aWN1bGFyIHRoZSBwdXp6bGUK ICAgZGlmZmljdWx0eSwgY2FyZSBtdXN0IGJlIHRha2VuLiAgSWYgdGhlIHB1enpsZXMgYXBw ZWFyZWQgdG9vIGVhc3kgZm9yCiAgIG1ham9yaXR5IG9mIHRoZSBhdHRhY2tlcnMsIHRoZW4g dGhlIHB1enpsZXMgbWVjaGFuaXNtIHdvdWxkbid0IGJlCiAgIGFibGUgdG8gcHJldmVudCBE b1MgYXR0YWNrIGFuZCB3b3VsZCBvbmx5IGltcG9zZSBhbiBhZGRpdGlvbmFsIGJ1cmRlbgog ICBvbiB0aGUgbGVnaXRpbWF0ZSBJbml0aWF0b3JzLiAgT24gdGhlIG90aGVyIGhhbmQsIGlm IHRoZSBwdXp6bGVzCiAgIGFwcGVhcmVkIHRvIGJlIHRvbyBoYXJkIGZvciBtYWpvcml0eSBv ZiB0aGUgSW5pdGlhdG9ycyB0aGVuIG1hbnkKICAgbGVnaXRpbWF0ZSB1c2VycyB3b3VsZCBl eHBlcmllbmNlIHVuYWNjZXB0YWJsZSBkZWxheSBpbiBJS0UgU0Egc2V0dXAKICAgKG9yIHVu YWNjZXB0YWJsZSBwb3dlciBjb25zdW1wdGlvbiBvbiBtb2JpbGUgZGV2aWNlcyksIHRoYXQg bWlnaHQKICAgY2F1c2UgdGhlbSB0byBjYW5jZWwgY29ubmVjdGlvbiBhdHRlbXB0LiAgSW4g dGhpcyBjYXNlIHRoZSByZXNvdXJjZXMKICAgb2YgdGhlIFJlc3BvbmRlciBhcmUgcHJlc2Vy dmVkLCBob3dldmVyIHRoZSBEb1MgYXR0YWNrIGNhbiBiZQogICBjb25zaWRlcmVkIHN1Y2Nl c3NmdWwuICBUaHVzIGEgc2Vuc2libGUgYmFsYW5jZSBzaG91bGQgYmUga2VwdCBieSB0aGUK ICAgUmVzcG9uZGVyIHdoaWxlIGNob29zaW5nIHRoZSBwdXp6bGUgZGlmZmljdWx0eSAtIHRv IGRlZmVuZCBpdHNlbGYgYW5kCiAgIHRvIG5vdCBvdmVyLWRlZmVuZCBpdHNlbGYuICBJdCBp cyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBwdXp6bGUKICAgZGlmZmljdWx0eSBiZSBjaG9zZW4g c28sIHRoYXQgdGhlIFJlc3BvbmRlcidzIGxvYWQgcmVtYWluIGNsb3NlIHRvCiAgIHRoZSBt YXhpbXVtIGl0IGNhbiB0b2xlcmF0ZS4gIEl0IGlzIGFsc28gUkVDT01NRU5ERUQgdG8gZHlu YW1pY2FsbHkKICAgYWRqdXN0IHRoZSBwdXp6bGUgZGlmZmljdWx0eSBpbiBhY2NvcmRhbmNl IHRvIHRoZSBjdXJyZW50IFJlc3BvbmRlcidzCiAgIGxvYWQuCgogICBTb2x2aW5nIHB1enps ZXMgcmVxdWlyZXMgYSBsb3Qgb2YgQ1BVIHBvd2VyLCB0aGF0IHdvdWxkIGluY3JlYXNlCiAg IHBvd2VyIGNvbnN1bXB0aW9uLiAgVGhpcyB3b3VsZCBpbmZsdWVuY2UgYmF0dGVyeS1wb3dl cmVkIEluaXRpYXRvcnMsCiAgIGUuZy4gbW9iaWxlIHBob25lcyBvciBzb21lIElvVCBkZXZp Y2VzLiAgSWYgcHV6emxlcyBhcmUgaGFyZCB0aGVuIHRoZQogICByZXF1aXJlZCBhZGRpdGlv bmFsIHBvd2VyIGNvbnN1bXB0aW9uIG1heSBhcHBlYXIgdG8gYmUgdW5hY2NlcHRhYmxlCiAg IGZvciBzb21lIEluaXRpYXRvcnMuICBUaGUgUmVzcG9uZGVyIFNIT1VMRCB0YWtlIHRoaXMg cG9zc2liaWxpdHkgaW50bwogICBjb25zaWRlcmF0aW9ucyB3aGlsZSBjaG9vc2luZyB0aGUg cHV6emxlcyBkaWZmaWN1bHR5IGFuZCB3aGlsZQogICBzZWxlY3Rpbmcgd2hpY2ggcGVyY2Vu dGFnZSBvZiBJbml0aWF0b3JzIGFyZSBhbGxvd2VkIHRvIHJlamVjdAogICBzb2x2aW5nIHB1 enpsZXMuICBTZWUgU2VjdGlvbiA3LjEuNCBmb3IgZGV0YWlscy4KCiAgIElmIHRoZSBJbml0 aWF0b3IgdXNlcyBOVUxMIEF1dGhlbnRpY2F0aW9uIFtSRkM3NjE5XSB0aGVuIGl0cyBpZGVu dGl0eQogICBpcyBuZXZlciB2ZXJpZmllZCwgdGhhdCBtYXkgYmUgdXNlZCBieSBhdHRhY2tl cnMgdG8gcGVyZm9ybSBEb1MKICAgYXR0YWNrIGFmdGVyIElLRSBTQSBpcyBlc3RhYmxpc2hl ZC4gIFJlc3BvbmRlcnMgdGhhdCBhbGxvdwogICB1bmF1dGhlbnRpY2F0ZWQgSW5pdGlhdG9y cyB0byBjb25uZWN0IG11c3QgYmUgcHJlcGFyZWQgZGVhbCB3aXRoCiAgIHZhcmlvdXMga2lu ZHMgb2YgRG9TIGF0dGFja3MgZXZlbiBhZnRlciBJS0UgU0EgaXMgY3JlYXRlZC4gIFNlZQog ICBTZWN0aW9uIDggZm9yIGRldGFpbHMuCgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0 dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDI5XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAg ICAgICAgTWFyY2ggMjAxNgoKCjEyLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgbmV3IHBheWxvYWQgaW4gdGhlICJJS0V2MiBQYXlsb2FkIFR5 cGVzIgogICByZWdpc3RyeToKCiAgICAgPFRCQT4gICAgICAgUHV6emxlIFNvbHV0aW9uICAg ICAgICAgICAgICAgICAgIFBTCgogICBUaGlzIGRvY3VtZW50IGFsc28gZGVmaW5lcyBhIG5l dyBOb3RpZnkgTWVzc2FnZSBUeXBlIGluIHRoZSAiSUtFdjIKICAgTm90aWZ5IE1lc3NhZ2Ug VHlwZXMgLSBTdGF0dXMgVHlwZXMiIHJlZ2lzdHJ5OgoKICAgICA8VEJBPiAgICAgICBQVVpa TEUKCiAgICAgMTMuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGUgYXV0aG9ycyB0aGFuayBU ZXJvIEtpdmluZW4sIFlhcm9uIFNoZWZmZXIgYW5kIFNjb3R0IEZsdWhyZXIgZm9yCiAgIHRo ZWlyIGNvbnRyaWJ1dGlvbiBpbnRvIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wuICBJbiBwYXJ0 aWN1bGFyLCBUZXJvCiAgIEtpdmluZW4gc3VnZ2VzdGVkIHRoZSBraW5kIG9mIHB1enpsZSB3 aGVyZSB0aGUgdGFzayBpcyB0byBmaW5kIGEKICAgc29sdXRpb24gd2l0aCByZXF1ZXN0ZWQg bnVtYmVyIG9mIHplcm8gdHJhaWxpbmcgYml0cy4gIFlhcm9uIFNoZWZmZXIKICAgYW5kIFNj b3R0IEZsdWhyZXIgc3VnZ2VzdGVkIGEgd2F5IHRvIG1ha2UgcHV6emxlIGRpZmZpY3VsdHkg bGVzcwogICBlcnJhdGljIGJ5IHNvbHZpbmcgc2V2ZXJhbCB3ZWFrZXIgcHV6bGVzLiAgVGhl IGF1dGhvcnMgYWxzbyB0aGFuawogICBEYXZpZCBXYWx0ZXJtaXJlIGZvciBoaXMgY2FyZWZ1 bGwgcmV2aWV3IG9mIHRoZSBkcmFmdCBhbmQgYWxsIG90aGVycwogICB3aG8gY29tbWVudGVk IHRoZSBkb2N1bWVudC4KCiAgICAgMTQuICBSZWZlcmVuY2VzCgogICAgICAgMTQuMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzCgogICAgICAgICAgICAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvCiAgICAgICAgICAgICAgSW5kaWNh dGUgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAg ICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0 cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgICAgICAgICAgICBb UkZDNzI5Nl0gIEthdWZtYW4sIEMuLCBIb2ZmbWFuLCBQLiwgTmlyLCBZLiwgRXJvbmVuLCBQ LiwKICAgICAgICAgICAgICBhbmQgVC4gS2l2aW5lbiwgIkludGVybmV0IEtleSBFeGNoYW5n ZSBQcm90b2NvbCBWZXJzaW9uIDIKICAgICAgICAgICAgICAoSUtFdjIpIiwgU1REIDc5LCBS RkMgNzI5NiwgRE9JIDEwLjE3NDg3L1JGQzcyOTYsIE9jdG9iZXIKICAgICAgICAgICAgICAy MDE0LCA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcyOTY+LgoKICAgICAg ICAgICAgICBbUkZDNzM4M10gIFNteXNsb3YsIFYuLCAiSW50ZXJuZXQgS2V5IEV4Y2hhbmdl IFByb3RvY29sCiAgICAgICAgICAgICAgVmVyc2lvbiAyIChJS0V2MikgTWVzc2FnZSBGcmFn bWVudGF0aW9uIiwgUkZDIDczODMsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzcz ODMsIE5vdmVtYmVyIDIwMTQsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM3MzgzPi4KCiAgIFtJS0VWMi1JQU5BXQogICAgICAgICAgICAgICJJ bnRlcm5ldCBLZXkgRXhjaGFuZ2UgVmVyc2lvbiAyIChJS0V2MikgUGFyYW1ldGVycyIsCiAg ICAgICAgICAgICAgPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWtldjItcGFy YW1ldGVycz4uCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRl bWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIw MTYKCgoxNC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW2JpdGNvaW5zXQogICAg ICAgICAgICAgIE5ha2Ftb3RvLCBTLiwgIkJpdGNvaW46IEEgUGVlci10by1QZWVyIEVsZWN0 cm9uaWMgQ2FzaAogICAgICAgICAgICAgIFN5c3RlbSIsIE9jdG9iZXIgMjAwOCwgPGh0dHBz Oi8vYml0Y29pbi5vcmcvYml0Y29pbi5wZGY+LgoKICAgICAgICAgICAgICBbUkZDNTcyM10g IFNoZWZmZXIsIFkuIGFuZCBILiBUc2Nob2ZlbmlnLCAiSW50ZXJuZXQgS2V5CiAgICAgICAg ICAgICAgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikgU2Vzc2lvbiBSZXN1 bXB0aW9uIiwKICAgICAgICAgICAgICBSRkMgNTcyMywgRE9JIDEwLjE3NDg3L1JGQzU3MjMs IEphbnVhcnkgMjAxMCwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzU3MjM+LgoKICAgICAgICAgICAgICBbUkZDNzYxOV0gIFNteXNsb3YsIFYu IGFuZCBQLiBXb3V0ZXJzLCAiVGhlIE5VTEwKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlv biBNZXRob2QgaW4gdGhlIEludGVybmV0IEtleSBFeGNoYW5nZQogICAgICAgICAgICAgIFBy b3RvY29sIFZlcnNpb24gMiAoSUtFdjIpIiwgUkZDIDc2MTksCiAgICAgICAgICAgICAgRE9J IDEwLjE3NDg3L1JGQzc2MTksIEF1Z3VzdCAyMDE1LAogICAgICAgICAgICAgIDxodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzYxOT4uCgogICAgICAgICAgICAgIFtSRkM3 Njk2XSAgSG91c2xleSwgUi4sICJHdWlkZWxpbmVzIGZvciBDcnlwdG9ncmFwaGljCiAgICAg ICAgICAgICAgQWxnb3JpdGhtIEFnaWxpdHkgYW5kIFNlbGVjdGluZyBNYW5kYXRvcnktdG8t SW1wbGVtZW50CiAgICAgICAgICAgICAgQWxnb3JpdGhtcyIsIEJDUCAyMDEsIFJGQyA3Njk2 LCBET0kgMTAuMTc0ODcvUkZDNzY5NiwKICAgICAgICAgICAgICBOb3ZlbWJlciAyMDE1LCA8 aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2OTY+LgoKQXV0aG9ycycgQWRk cmVzc2VzCgogICBZb2F2IE5pcgogICBDaGVjayBQb2ludCBTb2Z0d2FyZSBUZWNobm9sb2dp ZXMgTHRkLgogICA1IEhhc29sZWxpbSBzdC4KICAgVGVsIEF2aXYgIDY3ODk3MzUKICAgSXNy YWVsCgogICBFTWFpbDogeW5pci5pZXRmQGdtYWlsLmNvbQoKCiAgIFZhbGVyeSBTbXlzbG92 CiAgIEVMVklTLVBMVVMKICAgUE8gQm94IDgxCiAgIE1vc2NvdyAoWmVsZW5vZ3JhZCkgIDEy NDQ2MAogICBSdXNzaWFuIEZlZGVyYXRpb24KCiAgIFBob25lOiArNyA0OTUgMjc2IDAyMTEK ICAgRU1haWw6IHN2YW5AZWx2aXMucnUKCgoKICAgR3JhaGFtIEJhcnRsZXR0CiAgIENpc2Nv IFN5c3RlbXMKICAgMzAwIExvbmd3YXRlciBBdmVudWUKICAgUkVBRElORywgRU5HTEFORCBS RzIgNkdFCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5 LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgog ICBFTWFpbDogZ3JiYXJ0bGVAY2lzY28uY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJl cyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMzJdCg== --B_3540322596_35303241-- --B_3540322597_35303867 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgYnNl w3PZgMVMXcyVvk7iMisEod2Rcv88Fqeycw/CR1gwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzA4MjI1NjM2WjANBgkqhkiG9w0BAQEFAASCAQA7N+6h GlOPimAx92k1oG10sfBqlXaleC2o0At0DlvQkuMlckG/33xlE5SpwZkSrgmg3UPoWtNHZw2a Em2mU1dReTC093aANGVLubJvYxoP8t84piUUI4MNs5tzyRcNuUuDlWY1m1pFvHeLlW2RH7HH Zjdf5lJHA6U6W8sQenx1YkBT+Ewj+8fwWbjaOgC7sIbUmmrIBC8VUbMidema31vlIfIPvSDM 3xFy8QDlFW4DmycrbZX6iRpADznPpkMUR2ac6NK2CFWFUxdHIhEya8FtkJ2pvZZ2BYAk4Cu2 NbgkklGmBWbXasyXZ5oVT6OxFfOiG1irU1GjJf6diOEWUWvm --B_3540322597_35303867-- From nobody Wed Mar 9 03:46:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2701712D652 for ; Wed, 9 Mar 2016 03:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToF8xLqhYpGs for ; Wed, 9 Mar 2016 03:46:37 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A6812D64D for ; Wed, 9 Mar 2016 03:46:34 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x1so61199542lbj.3 for ; Wed, 09 Mar 2016 03:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=r/FN+GYLt7j2BnvDiBqsMvNbHvTdzMzzsx+poZeCO1I=; b=z6ueDHS6DnBP5jgjk9OtXtM2zw6oQfWFB9/xntxCwvleV9TQ+lYfhl8EYRO3vzWLG9 rtCtH2Fo4+RMl035l55kdQozAzFOqXJYkIHoME+BVPC6VPcM0aVyB+LNgkF+/Hk6NXrd xHHqD9iRS4aiT87jYHtaw3OiZAHXdQ0y5h/VSGW1pCkW8/rwo8Vv0uuSMav2SJpnbWe3 qjjz8jGpEFJCYVgwxdp16VMliV1z08iAKDLbydtqdeXwWEv1E9k5xF1uuFHUNnFMBikt uN0Z5lZCeQRLeOhrfV2wW2PTAC8xpAgADc96yZ2rgdT8JlQmqnevswrhDNys7nDTsVvr kI8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=r/FN+GYLt7j2BnvDiBqsMvNbHvTdzMzzsx+poZeCO1I=; b=S+b+DLz8ULfcRdj18malnLuqKfVF9bP/otLZcRorxo7f+lernsslWHjl6wpAmGemAR mO1ReggFVRD94OSUziOgtiCNQ/voS327RxjBS+TldFnIAZnTl88SFyUMrA5/fRo2iCca xYtL9607+BA5Hs1epn6xb1YddjZvSzzvyTa1/X5ffWdhDGZlYNMtU10AFY4RWa4xtPkP 4jBx/79xtyYKMaVfPWxLyyvL+MZ/RzdB17I/spQzRBpS+YutX3cEM0O7IAVvIOChsGtU df2Y/kZ2hjFwBamIBqYQTMDzje6BuZESgcICcetEJJfUWmXfAVivL5SUcxHUTG1keqlN QIWA== X-Gm-Message-State: AD7BkJLDzWZdwOuawOSjinxY/SBjwLcNngTooI8rQe5FCuJZyqjfDvbzBdxPm7ajmWVhGA== X-Received: by 10.25.83.8 with SMTP id h8mr2823576lfb.167.1457523992241; Wed, 09 Mar 2016 03:46:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o1sm1249149lbc.26.2016.03.09.03.46.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 03:46:31 -0800 (PST) Message-ID: <49C38BF405BA4D1F8EA9A8474352145A@buildpc> From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Yoav Nir" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> Date: Wed, 9 Mar 2016 14:46:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 11:46:40 -0000 Hi Graham, a few comments on your text. A number of attacks can occur if implementations use the HASH and URL, malicious parties can send a URL to redirect a VPN gateway to a server which does not contain the HASH of the certificate, but The server never contains hash, it contains the certificate (or CertBundle) matching the hash. instead contains a large file that is then downloaded by the VPN gateway consuming CPU and memory. For this reason the size of file pulled by the server SHOULD be limited to a certain value dictated by the policy for the issuing Certificate Authority. The VPN gateway I'm not sure if CAs have such a policy (there is a BasicConstraints extension in certificates, which is relevant, but not the same). Malicious or mis-configured clients can make numerous requests that exhaust the HTTP or TCP daemon running on the VPN gateway. The amount of requests that are performed in a given time should be monitored and rate limited should HTTP connections fail. The VPN gateway architecture should be designed so that the repository containing certificates is on the protected interface of the VPN gateway. This Sorry, this is impossible (if by "protected interface" you mean the interface protected by IPsec). That's a chicken-and-egg problem - you need to get the certificate before the SA is established (see Section 2 of RFC7296). Generally speaking, I don't think the attack is so serious. It is the IKE responder who retrieves data, so it is up to the responder to decide how much data it retrieves. The malicious http server cannot send more than one TCP window bytes unless the responder sends next ACK. And I think that the sane responder would read the first few bytes and determine the size of the whole ASN structure (certificate or CertBundle), since all the structures are required to be DER-encoded. And I agree with you that if the length is suspicious (e.g. greater than 16 KBs, which is more than enough to hold four certificates, the number - required to be supported by RFC7296), then it can just abort the TCP session. So I don's see it as an amplification attack that Yoav described - it is not full 4K moovie unless the responder is absolutely careless. Anyway, isn't the text better be placed in the Security Considerations section? Regards, Valery. > Hi > > I¹ve updated the draft (attached). Please see section 6.2, where I > describe a method to (potentially) pull your movie in 4k quality.. > > cheers > > On 06/03/2016 17:09, "Yoav Nir" wrote: > >>Sending a request and directing a server to send an entire movie in 4K >>quality using RTP in an interesting amplification attack. From nobody Wed Mar 9 15:26:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D942A12DB74 for ; Wed, 9 Mar 2016 15:26:39 -0800 (PST) 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 autolearn_force=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 06FoeeTzm87d for ; Wed, 9 Mar 2016 15:26:38 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DD14A12DB6C for ; Wed, 9 Mar 2016 15:26:37 -0800 (PST) Received: from [10.32.60.122] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u29NQafS095413 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2016 16:26:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "IPsecME WG" Date: Wed, 09 Mar 2016 15:26:36 -0800 Message-ID: <5EDDE822-A0A9-47CB-8976-5B3440BFC27E@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [IPsec] Revised version of draft-ietf-ipsecme-rfc4307bis? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 23:26:40 -0000 Greetings. We had kinda hoped to have this one wrapped up before the IETF meeting, but that is now seeming less likely. Will the authors have a revised draft based on the recent comments soon? --Paul Hoffman From nobody Wed Mar 9 15:29:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2C112D75D for ; Wed, 9 Mar 2016 15:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 jV0ENxjbZHbh for ; Wed, 9 Mar 2016 15:29:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 DB73112D6D0 for ; Wed, 9 Mar 2016 15:29:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qL8ky4mfdz3Dv; Thu, 10 Mar 2016 00:29:46 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Tl5bdGrggpl2; Thu, 10 Mar 2016 00:29:45 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 10 Mar 2016 00:29:45 +0100 (CET) Received: from [10.192.11.96] (unknown [41.250.182.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 23D066000315; Wed, 9 Mar 2016 18:29:43 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 23D066000315 References: <5EDDE822-A0A9-47CB-8976-5B3440BFC27E@vpnc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5EDDE822-A0A9-47CB-8976-5B3440BFC27E@vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7127518F-1A26-48DF-BBB2-FB2BE82E3062@nohats.ca> X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Wed, 9 Mar 2016 23:29:38 +0000 To: Paul Hoffman Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Revised version of draft-ietf-ipsecme-rfc4307bis? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 23:29:52 -0000 Yes we will, We've been talking at ICANN, I'll try to get it out tomorrow Sent from my iPhone > On Mar 9, 2016, at 23:26, Paul Hoffman wrote: >=20 > Greetings. We had kinda hoped to have this one wrapped up before the IETF m= eeting, but that is now seeming less likely. Will the authors have a revised= draft based on the recent comments soon? >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 9 23:07:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7704612D56B for ; Wed, 9 Mar 2016 23:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 TayXE8EsUFYm for ; Wed, 9 Mar 2016 23:07:45 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A3F12D55D for ; Wed, 9 Mar 2016 23:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10388; q=dns/txt; s=iport; t=1457593665; x=1458803265; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bmeJIX4xYVqCuH7kurYfkt4obPyMCkqoj5CFSUnjzmA=; b=B3twFWDOuSGd3GJTFX1lIT5GnnO+LB2ylIR3Jo1kx8YGykIvdb6Lk2v7 nUi8yGpSwfALIuK//AwJVnsSJcE6PvzRbgh1hd2lVMlxYkM4Z5rkYldo/ lqfaysAMkxWiF1inORrjRUERvvsuyUXK1HxoluaXWJyba2g0GQwXDwsoD Y=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAwDsG+FW/5hdJa1egztSbQa4PYITD?= =?us-ascii?q?oFtIYVuAiWBEzgUAQEBAQEBAWQnhEEBAQEDAUkwEAIBCA4EBiwCAh8RFw4CBAE?= =?us-ascii?q?JBAUOiAEDCggOkCidDwaKVQ2ERQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhhiEQ?= =?us-ascii?q?oI9gVcBDQQqKII8gUAFlzwBgxKBZYcGgXWBZIRGgyWFL4cYh0sBHgFDggACBhS?= =?us-ascii?q?BSGqIGAEfHX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,314,1454976000"; d="p7s'?scan'208";a="247538496" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2016 07:07:44 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2A77iJK011384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 07:07:44 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 01:07:43 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 01:07:43 -0600 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCT0HkAAA9+PoAAKAIqgAACBo+AAANw9YAANxCAgAADjbcAAHCyIwAADlGnTwAdXfgAABfBnIA= Date: Thu, 10 Mar 2016 07:07:43 +0000 Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <49C38BF405BA4D1F8EA9A8474352145A@buildpc> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3540438461_536109" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 07:07:47 -0000 --B_3540438461_536109 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable (Resending as my 1st attempt didn=A1=AFt seem to make it to the list..) Hi Valery On 09/03/2016 11:46, "Valery Smyslov" wrote: >Hi Graham, > >a few comments on your text. > > A number of attacks can occur if implementations use the HASH and > URL, malicious parties can send a URL to redirect a VPN gateway to a > server which does not contain the HASH of the certificate, but > >The server never contains hash, it contains the certificate (or >CertBundle) >matching the hash. Thanks - sorry, I used the wrong terminology. Just to confirm - for the malicious case I setup my webserver www.evilgraham.com, I send you HASH + URL http://www.evilgraham.com/djfjkdfkdfkdfjfdj (hash being 'djfjkdfkdfkdfjfdj') there=A1=AFs a file on my server named =A1=AEdjfjkdfkdfkdfjfdj=A1=AF (Yoav=A1=AFs 4k movie.= .) You now download this movie.. > > instead contains a large file that is then downloaded by the VPN > gateway consuming CPU and memory. For this reason the size of file > pulled by the server SHOULD be limited to a certain value dictated by > the policy for the issuing Certificate Authority. The VPN gateway > >I'm not sure if CAs have such a policy (there is a BasicConstraints >extension >in certificates, which is relevant, but not the same). Sorry - I wasn=A1=AFt clear. I was referring to security policy for the CA. So say your CA issues certs with a RSA 2048bit keypair, you would know the approx size of the certificates generated. You would know not to download a cert bigger than X bytes. As I understand some certificate can become very large (if containing images etc..), there=A1=AFs no hard set limit on a certifciate size, but the =A1=AEsecurity policy' for the CA (what attributes are included would be known), so an informed decision could be made to the size of the certificates. > > Malicious or mis-configured clients can make numerous requests that > exhaust the HTTP or TCP daemon running on the VPN gateway. The amount > of requests that are performed in a given time should be monitored > and rate limited should HTTP connections fail. The VPN gateway > architecture should be designed so that the repository containing > certificates is on the protected interface of the VPN gateway. This > >Sorry, this is impossible (if by "protected interface" you mean >the interface protected by IPsec). That's a chicken-and-egg problem - >you need to get the certificate before the SA is established >(see Section 2 of RFC7296). I don=A1=AFt mean IPsec protected interface. Think LAN and WAN. So IKE/IPsec comes into the WAN interface and then your protected networks are on your LAN. Maybe better terminology would have been Management, basically an interface that isn=A1=AFt internet (or WAN) facing and not accessible by the IKE clients (so can=A1=AFt be turned over). I=A1=AFll reword this, thanks for the pointer. > > >Generally speaking, I don't think the attack is so serious. >It is the IKE responder who retrieves data, so it is up to the responder >to decide how much data it retrieves. The malicious http server cannot >send >more than one TCP window bytes unless the responder sends next ACK. >And I think that the sane responder would read the first few bytes >and determine the size of the whole ASN structure (certificate or >CertBundle), >since all the structures are required to be DER-encoded. >And I agree with you that if the length is suspicious (e.g. >greater than 16 KBs, which is more than enough to hold >four certificates, the number - required to be supported by RFC7296), >then it can just abort the TCP session. But there=A1=AFs also the case for someone getting the VPN gateway to connect to a malicious HTTP server, even for the 16k limit they can drip feed the file (very slow transfer). Do this a number of times and you could exhaust all TCP sockets on the VPN gateway (maybe then preventing CRLs being retried etc). >So I don's see it as an amplification attack that Yoav described - >it is not full 4K moovie unless the responder is absolutely careless. Well - for those careless responders it=A1=AFs 2 packets to the get the VPN gateway to download the movie (200k+ packets etc=A1=A6) Seems like a nice amplification to me. >Anyway, isn't the text better be placed in the Security Considerations >section? Sure - I can put it in there. I=A1=AFll tidy up the words to clear up the confusion. Thanks for the comments Valery. cheers > >Regards, >Valery. > > > >>Hi >> >>I=A9=F6ve updated the draft (attached). Please see section 6.2, where I >>describe a method to (potentially) pull your movie in 4k quality.. >> >>cheers >> >>On 06/03/2016 17:09, "Yoav Nir" wrote: >> >>>Sending a request and directing a server to send an entire movie in 4K >>>quality using RTP in an interesting amplification attack. > > --B_3540438461_536109 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg5KBD xJ+EDTdB6mVLNEdsUw4vT99PT/NZsj5tQMfhoWEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzEwMDcwNzQxWjANBgkqhkiG9w0BAQEFAASCAQATRQCL XRevV9W5Zg/Iy9OuJHbix5Xbi9J0/Kspf563XLgzs8EjU+4QwqTO8oB7EWfH0MeqPHKmkecM MkocqKZ4+MZhTmJuQ/5hyix9TSEdTHDV6+Mx+EYSCsazTv1cwfx5WT5MnXL/+shI+AZpB4s/ FyobJ1gAcenOdEER/anOh4okkwzDw299JYQNHZRKdgVm3czc//QmD8nmiKCpPZs5rjKwYHZ4 kr5CTccdu05uEy6oPRuF9Tze8y3NE9QpswvY9A78oTRUefKRi4ZGehJVCIw9l/qYmW9LbNEs 7K440mUPN04PqS4WV3gLhfTOUlCCgBzJAapW7h2tzS7bHKvS --B_3540438461_536109-- From nobody Thu Mar 10 15:55:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4612DEE6 for ; Thu, 10 Mar 2016 15:55:12 -0800 (PST) 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 autolearn_force=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 JvfOwPslhqeM for ; Thu, 10 Mar 2016 15:55:11 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 3B72612DEC8 for ; Thu, 10 Mar 2016 15:55:11 -0800 (PST) Received: from [10.32.60.127] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2ANt9ik014712 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2016 16:55:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.127] From: "Paul Hoffman" To: "IPsecME WG" Date: Thu, 10 Mar 2016 15:55:09 -0800 Message-ID: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 23:55:12 -0000 https://www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme Comments are welcome. Of course, this is not an invitation to stop conversation before the meeting; just the opposite. Please keep the on-list discussion active so that the meeting can be more useful. --Dave Waltermire and Paul Hoffman From nobody Thu Mar 10 21:52:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8878812D507 for ; Thu, 10 Mar 2016 21:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UMTY6eKv4U5z for ; Thu, 10 Mar 2016 21:52:53 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1D312D508 for ; Thu, 10 Mar 2016 21:52:52 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id bc4so141609588lbc.2 for ; Thu, 10 Mar 2016 21:52:52 -0800 (PST) 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-transfer-encoding; bh=eVVad3NTTtWtEGmfieIgkeeZRWsLRxr3HMFdzN/dzrQ=; b=D5gq2/Dhou7ep6KPfNUpvj4y08FetUfps5QV8POS4qfriIi0HHpO2xEmlBxbBmVhrO P8D68QuFcjGPYPtoHaAlJk/8M7mLridn3Rzk7m6lw+ZJ41hXRZ9G1mytwv8kl9nK6QJA G/Kd6Fu6Pn6SlF6Ug6pdQwZmAAl5IUeg4pRpVp3Vg/879Zoe+obLWZYSh38Cuj8FSf8G xggVFI+KEsBAaXNLggfvyzZU0gNKQairWujK0YiAu3fMM+XfXTeBupN2UlJJbp82YrBF rhB1YgaY/Oq3oJAU2T60jji6WWtLcz4TNzG7GU0fQK9EanKJqhsu7rtS1r+T2LqIi7BI B5rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=eVVad3NTTtWtEGmfieIgkeeZRWsLRxr3HMFdzN/dzrQ=; b=Q+vsRqgRPv0Fssl1jNx0A9yj0fUdYa3Zs5dhhMbWbVx2md7SxQuo3qCLq8m2shiFRh rtHX4Grzkl7+HCKVPU1jdGOh3yckv+08xujoa+/aJ92t3ydW8m0r3orNJ6FBYYc6huBB 7IUeiueI3sl5H9Pxt2peO3okiB5HjTR/826h/cOwBnXVYzDto7buznvulXcPukgReiNw fv0rH1S2B7os77WKufz9mtTGPpJijqwYjifpqaqO1uXHlOq30fn/uFL0vK5UYC0DyWlk TIX2bbyHhnGXvwm31+7KAVITQ7ADob7aAuORxT/kWrpHM4ONudbZ1w1QexPGPTFpFo2E MdKQ== X-Gm-Message-State: AD7BkJLqSYpmGjcGkaQbMecYzgQRN01d0Awqu2BeJdOPpyycB8elapCNbU2fdHwn+LuMMA== X-Received: by 10.112.211.168 with SMTP id nd8mr2485520lbc.116.1457675570766; Thu, 10 Mar 2016 21:52:50 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id ke9sm1064300lbc.28.2016.03.10.21.52.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2016 21:52:49 -0800 (PST) Message-ID: <65CCA023671744E1A20A53F88D310D94@buildpc> From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> Date: Fri, 11 Mar 2016 08:52:58 +0300 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: Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 05:52:54 -0000 Hi Paul, I'd like to make a short presentation (~10 min) about using compression in IKEv2 (draft-smyslov-ipsecme-ikev2-compression). I'm also a bit puzzled that there is nothing in the agenda concerning the yang data model for IPsec. I remember in Prague authors promised to merge their drafts and to present a new model. I see the new draft issued, but I heard no details of what was changed (and why), and what are the next steps. Regards, Valery. > https://www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme > > Comments are welcome. > > Of course, this is not an invitation to stop conversation before the > meeting; just the opposite. Please keep the on-list discussion active so > that the meeting can be more useful. > > --Dave Waltermire and Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 10 23:13:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0712D526 for ; Thu, 10 Mar 2016 23:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 do5ajnCmp1He for ; Thu, 10 Mar 2016 23:13:45 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557F612D539 for ; Thu, 10 Mar 2016 23:13:45 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id p65so5502189wmp.0 for ; Thu, 10 Mar 2016 23:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0aRtpCcHpxSOxoDlQCBTOq6uoEV4tpEyjFTvSB1uDRA=; b=FhfFxRS3lNoWMvA1BFXpJPElqHnQm02PnavNMPW10p5tv67nBxR0BolzexywoPYSc4 T9d5dJfcDRiXKm8DbZRDeC6IQWSSGFtarMF88xIM4Ozc4XfrRf4c/hLqg7XjAI1KQHdq 9ZOZhnFPQ1PqPXn/riEwLm/WGp9HqEicIDErf4opDMNh79o1IFZePdTKPOf13XDYl5WP ZrCkIPWNve8PmHRMDgjjmSIp1M8m2fdtcM4kC3RLl8/LABCdWaC/+8qygnWaFt9K+g00 jytfAONTIlFUftQA+N3FwHi137tv1AqqMA+JQluvw/y9Ma0rdcZToTd5VJjYdURpkuwB IQRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0aRtpCcHpxSOxoDlQCBTOq6uoEV4tpEyjFTvSB1uDRA=; b=lWAI/Uaa1y2mgVcdIPPsx8NPCZhn2ig/7floDz5E5iaO/FT52QT7JB/7tWdRkjNK2T x1IRMzaYb9zfjx4Sls7mkgD7EPG9NSF6b0c6TPuKHl3iXVy7/MMz/T0sgvJmoMjAP/mU VMaEB02frzePmfI0rgAiyvuRazCr+59zwbxMntL3rdXTFcWg+LKPj0YG82Xp9wIcwV7o BxNfL0swMHy/ZwNmaxdo7pqdrKlNtUwDN9k3ElVuxALz/JG5N0/5kxz6zoj6WDZMlpWb KqA99jMpR4dmqRqCOJehrHSRKdH0nORZcrEuuLFV652ogMM4FL4TKiLlE0XXnY3rNZJS CLZg== X-Gm-Message-State: AD7BkJI97w1TF+Ox0fy24D3Uk0P0yLUXYn7D/EoWZGVrPnFQJjvCuBmYpjq40u6+GUxdkA== X-Received: by 10.28.51.74 with SMTP id z71mr1062098wmz.15.1457680423868; Thu, 10 Mar 2016 23:13:43 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id i2sm7001851wje.22.2016.03.10.23.13.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 23:13:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> Date: Fri, 11 Mar 2016 09:13:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8852860D-10AF-458B-A622-E2865B83C2F8@gmail.com> References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 07:13:48 -0000 Regarding draft-ietf-ipsecme-safecurves I think this is pretty much done. I don=E2=80=99t see why I=E2=80=99d = need 15 minutes to say, =E2=80=9CVersion -00 had Curve25519; version -01 = added Curve448; we don=E2=80=99t need to wait for CFRG=E2=80=99s = signature draft, because we have RFC 7427; I think we=E2=80=99re ready = for WGLC=E2=80=9D Yoav > On 11 Mar 2016, at 1:55 AM, Paul Hoffman = wrote: >=20 > https://www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme >=20 > Comments are welcome. >=20 > Of course, this is not an invitation to stop conversation before the = meeting; just the opposite. Please keep the on-list discussion active so = that the meeting can be more useful. >=20 > --Dave Waltermire and Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 11 04:55:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883C412D6C6 for ; Fri, 11 Mar 2016 04:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 96owT7ECT_DY for ; Fri, 11 Mar 2016 04:55:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 6CAF312D6B5 for ; Fri, 11 Mar 2016 04:55:50 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qM6ZX3JWXz1xf; Fri, 11 Mar 2016 13:55:48 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BWUrS1_CJzz4; Fri, 11 Mar 2016 13:55:46 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 11 Mar 2016 13:55:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5E5AC6000315; Fri, 11 Mar 2016 07:55:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5E5AC6000315 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A14DA3C7; Fri, 11 Mar 2016 07:55:45 -0500 (EST) Date: Fri, 11 Mar 2016 07:55:45 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> Message-ID: References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 12:55:51 -0000 On Thu, 10 Mar 2016, Paul Hoffman wrote: > > https: //www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme > > Comments are welcome. > > Of course, this is not an invitation to stop conversation before the meeting; > just the opposite. Please keep the on-list discussion active so that the > meeting can be more useful. I would like to discuss the IKEv2 IANA registries and the requirements for new code points. This is in response to Tero's comments regarding the latest non-WG entry for a 3gpp extension that was never passed through the working group. Tero's suggestion was to "allow it this time", which really begs the question on how we will handle this in the future. Paul From nobody Fri Mar 11 06:07:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F278B12D6F4 for ; Fri, 11 Mar 2016 06:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ymp3MHECmc0M for ; Fri, 11 Mar 2016 06:07:31 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6A912D6FE for ; Fri, 11 Mar 2016 06:07:31 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id p65so19442694wmp.1 for ; Fri, 11 Mar 2016 06:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=z4SsHxz5DCkmjCZXUQ+4eGxfTnpJ7ZctbXMyur9BNgo=; b=CxpSsCmURzm+zavgS2brRMzI+0AWaxi1JZ2Ub3aNTIh0Rj8E4eM2/jjl6+BcA0hnCf xlXOnzFPLpH9y1BjSouo+R44rUaweCveY+cwrWpvf/0lAO2pAuS3oxWDWAe9S9G4c6Mf wmclhYpAD6bEbuMBqxO58zTwLjSr1vdNxI2lWmcO5g/mvBlLumJSyDTw+bYOoL67rI1v 3plWTxcDE2+5v0d+i4V9jLKxvzLhOcVsfe/C+dWyONLgEYOwEMSj+HUFTj7Vpw9PBqIT qxR803GcC12/tR2MVmNv5bZvGm9I1hHj5ZET1AQ+EUpsWJJ0bEFKTCNDW+uDM0igGu97 5OiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=z4SsHxz5DCkmjCZXUQ+4eGxfTnpJ7ZctbXMyur9BNgo=; b=LzpUzxRWwBjG696ZsuyStkV6Hju4xxQJT3bUJOGeJjd4Aop0dsIokgAiIxNp8fhNIX ioB28BZMglEDWvvfa+g4GsjEO3yfHmpLfgDrO3OWHvPc1jQ2w5q2rJrzMeHK1Ks+DTGb gNhYSYwZ7rLP3HYAcv2csP7Plz4sGSlY01j+S8xBT46pHEqKd2lvgsIXO8pcxbv5nn2R DkOFSeGPIkfHZeBqba9G6C9FFE2THmAiBqB6/hVvXWzHT24OcC1W8v6y10NUBgn0ngO6 jEgCBCyZxX9/l5rrmWn+bM2moRSZ2ZfsaISbG//mKseTzvuOL8ze3vAma+0FcveZ0GcL IfvA== X-Gm-Message-State: AD7BkJKP3BApuWaCi0uWEKfTxC+kERfOjRCEmX9bJfkMjpHhiiM3yULYbwfLKdm3vzrOILJRAgVSTCXuOqHmgg== MIME-Version: 1.0 X-Received: by 10.194.246.35 with SMTP id xt3mr10796991wjc.57.1457705250030; Fri, 11 Mar 2016 06:07:30 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.78.199 with HTTP; Fri, 11 Mar 2016 06:07:29 -0800 (PST) In-Reply-To: References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> Date: Fri, 11 Mar 2016 14:07:29 +0000 X-Google-Sender-Auth: FgKV32kXvLxoKQkzgHPq5oOE3VE Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c3a21a9d8db8052dc6734e Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 14:07:34 -0000 --001a11c3a21a9d8db8052dc6734e Content-Type: text/plain; charset=UTF-8 Hi everyone, I would also be more than happy to present our ongoing work on IKEv2/YANG. BR Daniel On Fri, Mar 11, 2016 at 12:55 PM, Paul Wouters wrote: > On Thu, 10 Mar 2016, Paul Hoffman wrote: > > >> https: //www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme >> >> Comments are welcome. >> >> Of course, this is not an invitation to stop conversation before the >> meeting; just the opposite. Please keep the on-list discussion active so >> that the meeting can be more useful. >> > > I would like to discuss the IKEv2 IANA registries and the requirements > for new code points. This is in response to Tero's comments regarding > the latest non-WG entry for a 3gpp extension that was never passed > through the working group. Tero's suggestion was to "allow it this > time", which really begs the question on how we will handle this in the > future. > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11c3a21a9d8db8052dc6734e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I would also be more than h= appy to present our ongoing work on IKEv2/YANG.

BR

Daniel

On Fri, Mar 11, 2016 at 12:55 PM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 10 Mar = 2016, Paul Hoffman wrote:


https: //www.ietf.org/proceedings/95/agen= da/agenda-95-ipsecme

Comments are welcome.

Of course, this is not an invitation to stop conversation before the meetin= g; just the opposite. Please keep the on-list discussion active so that the= meeting can be more useful.

 I would like to discuss the IKEv2 IANA registries and the requirements
for new code points. This is in response to Tero's comments regarding the latest non-WG entry for a 3gpp extension that was never passed
through the working group. Tero's suggestion was to "allow it this=
time", which really begs the question on how we will handle this in th= e
future.

Paul


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

--001a11c3a21a9d8db8052dc6734e-- From nobody Fri Mar 11 07:56:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4223212D81A for ; Fri, 11 Mar 2016 07:56:27 -0800 (PST) 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 autolearn_force=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 VRHD-0F5aAds for ; Fri, 11 Mar 2016 07:56:25 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8F82E12D7E8 for ; Fri, 11 Mar 2016 07:56:25 -0800 (PST) Received: from [10.32.60.73] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2BFuMHR066648 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2016 08:56:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.73] From: "Paul Hoffman" To: "Valery Smyslov" Date: Fri, 11 Mar 2016 07:56:21 -0800 Message-ID: <1D6F104A-74D1-4AC1-A60B-12450E7DBB79@vpnc.org> In-Reply-To: <65CCA023671744E1A20A53F88D310D94@buildpc> References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> <65CCA023671744E1A20A53F88D310D94@buildpc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 15:56:27 -0000 On 10 Mar 2016, at 21:52, Valery Smyslov wrote: > I'd like to make a short presentation (~10 min) about using > compression in IKEv2 > (draft-smyslov-ipsecme-ikev2-compression). Sorry, we totally spaced that out. We'll add it. > I'm also a bit puzzled that there is nothing in the agenda > concerning the yang data model for IPsec. I remember in Prague > authors promised to merge their drafts and to present > a new model. I see the new draft issued, but I heard no details of > what > was changed (and why), and what are the next steps. As you point out, the authors already had time to do an initial presentation. Since then, there has been no discussion on the mailing list. Using face-to-face meeting time to discuss things that are not discussed on the list is not a good use of our time. If the Yang model stuff starts being discussed on the list and there is sufficient interest, we should talk about it at future meetings or even at a virtual interim. --Paul Hoffman From nobody Fri Mar 11 07:57:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5512D839 for ; Fri, 11 Mar 2016 07:57:34 -0800 (PST) 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 autolearn_force=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 Xtg95O4JAXXt for ; Fri, 11 Mar 2016 07:57:33 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 67EB012D7E8 for ; Fri, 11 Mar 2016 07:57:28 -0800 (PST) Received: from [10.32.60.73] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2BFvQ1a066673 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2016 08:57:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.73] From: "Paul Hoffman" To: "Yoav Nir" Date: Fri, 11 Mar 2016 07:57:25 -0800 Message-ID: In-Reply-To: <8852860D-10AF-458B-A622-E2865B83C2F8@gmail.com> References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> <8852860D-10AF-458B-A622-E2865B83C2F8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 15:57:34 -0000 On 10 Mar 2016, at 23:13, Yoav Nir wrote: > Regarding draft-ietf-ipsecme-safecurves > > I think this is pretty much done. I don’t see why I’d need 15 > minutes to say, “Version -00 had Curve25519; version -01 added > Curve448; we don’t need to wait for CFRG’s signature draft, > because we have RFC 7427; I think we’re ready for WGLC†Great! I've cut down the time allotment for it then. Of course, you could say that on the list in a separate thread so that we'll start the WG Last Call sooner... --Paul Hoffman From nobody Fri Mar 11 07:59:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8370412D839 for ; Fri, 11 Mar 2016 07:59:50 -0800 (PST) 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 autolearn_force=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 KVLUqB3Gw7ka for ; Fri, 11 Mar 2016 07:59:49 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 BE6F912D615 for ; Fri, 11 Mar 2016 07:59:36 -0800 (PST) Received: from [10.32.60.73] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2BFxZ4G066706 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2016 08:59:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.73] From: "Paul Hoffman" To: "Paul Wouters" Date: Fri, 11 Mar 2016 07:59:35 -0800 Message-ID: <9E7E6A95-8E54-4304-AE46-CE7C3ADFA4E2@vpnc.org> In-Reply-To: References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 15:59:50 -0000 On 11 Mar 2016, at 4:55, Paul Wouters wrote: > I would like to discuss the IKEv2 IANA registries and the requirements > for new code points. This is in response to Tero's comments regarding > the latest non-WG entry for a 3gpp extension that was never passed > through the working group. Tero's suggestion was to "allow it this > time", which really begs the question on how we will handle this in > the > future. That seems to be a reasonable topic for discussion. Could you (or you and Tero) put together a proposal and do 10 minutes on it? --Paul Hoffman From nobody Fri Mar 11 08:00:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BFF12D8C6 for ; Fri, 11 Mar 2016 08:00:27 -0800 (PST) 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 autolearn_force=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 tg209eIh07w1 for ; Fri, 11 Mar 2016 08:00:24 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0AA6E12D8A6 for ; Fri, 11 Mar 2016 08:00:19 -0800 (PST) Received: from [10.32.60.73] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2BG0DH0066753 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2016 09:00:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.73] From: "Paul Hoffman" To: "Daniel Migault" Date: Fri, 11 Mar 2016 08:00:13 -0800 Message-ID: <2B7F41A4-366F-4543-81DB-2FEF91F22E45@vpnc.org> In-Reply-To: References: <575ADD0A-E23C-4140-B11F-ACF202E91C01@vpnc.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 16:00:27 -0000 On 11 Mar 2016, at 6:07, Daniel Migault wrote: > I would also be more than happy to present our ongoing work on IKEv2/YANG. Great! Please so do on the list. :-) --Paul Hoffman From nobody Sat Mar 12 08:40:54 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 506A412DDA5; Fri, 11 Mar 2016 15:05:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230528.15028.79080.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:28 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 08:40:53 -0800 Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 95 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:28 -0000 Dear D. Waltermire, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30:00) Monday, Afternoon Session I 1400-1530 Room Name: Quebracho A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: D. Waltermire Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: dnsop dane dprive dbound curdle jsonbis saag sacm netmod mile httpauth Special Requests: Additional BOF conflicts: lurk and accord --------------------------------------------------------- From nobody Mon Mar 14 02:58:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762FC12D1E5 for ; Mon, 14 Mar 2016 02:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tvo6RCiDdTtF for ; Mon, 14 Mar 2016 02:58:43 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3763612D519 for ; Mon, 14 Mar 2016 02:49:47 -0700 (PDT) Received: by mail-lb0-x22c.google.com with SMTP id xr8so225787404lbb.1 for ; Mon, 14 Mar 2016 02:49:47 -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; bh=td1HYeNaklMDg8DpFbcZBHkTiuzG01m2c4Kp4z+qAQQ=; b=rrXKfn2lZg+3nbZWYfMMP8NjyZ3YMpJNoRxERd7NmyUAqWQLqnRe6CWfMvTDMRybiF tz/uWaafYIgbqE76/acBwiwqn+f817dkDA1mKFQw/ygGZJqQj0m0cfTjBoY9RiM1klKM 3lDaE4vcrBc/LHAx++66wbz9MrlrmpDxRrMg0XgudM8n84WhS++2i1NQVAl8JliRrrAJ wECFC49zIEJILTjIY8BM3dSFlqKkXP98EaOiCweSRMeT9cWhuUHGut7g35cOib+kP3OA WNyFDUkO+h/EPuqTQoGobTaKn5gBLw/MFV7BWYE9/7i7Ay95TIGddD1ust00SxHZDq+U aARw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=td1HYeNaklMDg8DpFbcZBHkTiuzG01m2c4Kp4z+qAQQ=; b=hHENEaN/FtUQawyd0rAkcOjW/zArGk4EumbywvnWDnLtsg9U+wfUHtPfVQYcS7Z0W2 c98aXqGT0hH1ucF+D7j7lroyNVzbJYIHahC99gEAzg0dZEWCIEyXsEbdhuPKSWJEyPZy KgXi9Ac3pxGu8+OYdR0PR283Iv93Bz++L2GGXcYFGLyRwhYLcJBY8p64i58EOFydJAO8 tJN26vFMuXEqIzn1wKi6lBhTnmfKZLFi4qWYq0qS1wYN45y9XipCro35dAUB1rUaq6b4 hQ50aS9VeueIw8Z6ZZUg9n4SQw7ERDCyQyQtOebasz0BrasMeeLINwqu+0WVG1LrpGal tp7w== X-Gm-Message-State: AD7BkJLeCEZEv42FBo4Su9MVYcvy4jdgdjVdtPUDWgWQVX1avIvIQA7NRZQBS2UEPFPZcZFE4yXarHFQtFXm+A== MIME-Version: 1.0 X-Received: by 10.112.29.4 with SMTP id f4mr7370331lbh.92.1457948985338; Mon, 14 Mar 2016 02:49:45 -0700 (PDT) Received: by 10.25.29.141 with HTTP; Mon, 14 Mar 2016 02:49:45 -0700 (PDT) In-Reply-To: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> Date: Mon, 14 Mar 2016 10:49:45 +0100 Message-ID: From: Daniel Palomares To: IPsecME WG Content-Type: multipart/alternative; boundary=001a1133f7525f31a0052dff33e9 Archived-At: Cc: Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 09:58:45 -0000 --001a1133f7525f31a0052dff33e9 Content-Type: text/plain; charset=UTF-8 Hello, I would like to propose MOBIKEv2 as part of the charter. What it basically proposes is to add MOBIKE support for Transport Mode (and not only tunnel mode). The most suitable scenarios that would benefit from this are any-to-any networks implementing IPsec in transport mode. MOBIKEv2 has already been presented at the ietf>ipsecme meetings. BR, Daniel Palomares > On Tue, Mar 1, 2016 at 4:18 PM, Paul Hoffman > wrote: > >> Greetings. We need to update our charter to reflect our current and >> expected work. Dave and I propose the following text. Please let us know >> within the next week if you have suggestions for changes. >> >> --Paul Hoffman and Dave Waltermire >> >> >> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated >> RFCs), >> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is >> widely deployed in VPN gateways, VPN remote access clients, and as a >> substrate for host-to-host, host-to-network, and network-to-network >> security. >> >> The IPsec Maintenance and Extensions Working Group continues the work of >> the earlier IPsec Working Group which was concluded in 2005. Its purpose >> is >> to maintain the IPsec standard and to facilitate discussion of >> clarifications, >> improvements, and extensions to IPsec, mostly to IKEv2. >> The working group also serves as a focus point for other IETF Working >> Groups >> who use IPsec in their own protocols. >> >> The current work items include: >> >> IKEv2 contains the cookie mechanism to protect against denial of service >> attacks. However this mechanism cannot protect an IKE end-point >> (typically, >> a large gateway) from "distributed denial of service", a coordinated >> attack by >> a large number of "bots". The working group will analyze the problem and >> propose a solution, by offering best practices and potentially by >> extending >> the protocol. >> >> IKEv2 utilizes a number of cryptographic algorithms in order to provide >> security services. To support interoperability a number of mandatory-to- >> implement (MTI) algorithms are defined in RFC4307. There is interest in >> updating the MTIs in >> RFC4307 based on new algorithms, changes to the understood security >> strength of existing algorithms, and the degree of adoption of previously >> introduced algorithms. The group will revise RFC4307 proposing updates to >> the MIT algorithms used by IKEv2 to address these changes. >> >> There is interest in supporting Curve25519 and Curve448 for ephemeral key >> exchange in the IKEv2 protocol. The group will extend the >> IKEv2 protocol to support key agreement using these curves and their >> related functions. >> >> This charter will expire in August 2016. If the charter is not updated >> before >> that time, the WG will be closed and any remaining documents revert back >> to >> individual Internet-Drafts. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > --001a1133f7525f31a0052dff33e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I would like to propose MOBI= KEv2 as part of the charter.

What it basically= proposes is to add MOBIKE support for Transport Mode (and not only tunnel = mode). The most suitable scenarios that would benefit from this are any-to-= any networks implementing IPsec in transport mode.

MOBIKE= v2 has already been presented at the ietf>ipsecme meetings.

BR,

Daniel Palomares


On Tue, Mar 1, 2016 at 4:18 PM, Pa= ul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings. We need to update our cha= rter to reflect our current and expected work. Dave and I propose the follo= wing text. Please let us know within the next week if you have suggestions = for changes.

--Paul Hoffman and Dave Waltermire


The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),=
IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is<= br> widely deployed in VPN gateways, VPN remote access clients, and as a
substrate for host-to-host, host-to-network, and network-to-network
security.

The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is=
to maintain the IPsec standard and to facilitate discussion of clarificatio= ns,
improvements, and extensions to IPsec, mostly to IKEv2.
The working group also serves as a focus point for other IETF Working Group= s
who use IPsec in their own protocols.

The current work items include:

IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically,=
a large gateway) from "distributed denial of service", a coordina= ted attack by
a large number of "bots". The working group will analyze the prob= lem and
propose a solution, by offering best practices and potentially by extending=
the protocol.

IKEv2 utilizes a number of cryptographic algorithms in order to provide
security services. To support interoperability a number of mandatory-to- implement (MTI) algorithms are defined in RFC4307. There is interest in
updating the MTIs in
RFC4307 based on new algorithms, changes to the understood security
strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 proposing updates to the MIT algorithms used by IKEv2 to address these changes.

There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange in the IKEv2 protocol. The group will extend the
IKEv2 protocol to support key agreement using these curves and their
related functions.

This charter will expire in August 2016. If the charter is not updated befo= re
that time, the WG will be closed and any remaining documents revert back to=
individual Internet-Drafts.




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

--001a1133f7525f31a0052dff33e9-- From nobody Mon Mar 14 03:46:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9D12DA4B for ; Mon, 14 Mar 2016 03:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 Spp-3i50kolf for ; Mon, 14 Mar 2016 03:45:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C23D512D989 for ; Mon, 14 Mar 2016 03:45:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qNvYD18m4zvk; Mon, 14 Mar 2016 11:45:52 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DSjKRTWccDc3; Mon, 14 Mar 2016 11:45:49 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 14 Mar 2016 11:45:49 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 19FD96066252; Mon, 14 Mar 2016 06:45:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 19FD96066252 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1851CA3C7; Mon, 14 Mar 2016 06:45:49 -0400 (EDT) Date: Mon, 14 Mar 2016 06:45:49 -0400 (EDT) From: Paul Wouters To: Daniel Palomares In-Reply-To: Message-ID: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 10:45:59 -0000 On Mon, 14 Mar 2016, Daniel Palomares wrote: > I would like to propose MOBIKEv2 as part of the charter. > > What it basically proposes is to add MOBIKE support for Transport Mode (and not only tunnel mode). The most suitable scenarios that would > benefit from this are any-to-any networks implementing IPsec in transport mode. I dont even understand how that would work in transport mode, but I'm not a MOBIKE expert. Probably best to discuss this in the working group, then when the workgring group sees this as something to work on, we could add it to the charter? Paul From nobody Tue Mar 15 08:26:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF78B12DAAD for ; Tue, 15 Mar 2016 08:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zV_PBWrThAGo for ; Tue, 15 Mar 2016 08:26:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AB112DAD7 for ; Tue, 15 Mar 2016 08:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7041; q=dns/txt; s=iport; t=1458055560; x=1459265160; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IfPSB9zfCHEnruZ/XIgpYG4/lByrAC+SN35PlPDSV8U=; b=DbW24phU4BgUhCB1QnHHHP6k6RTE1Xpnet0ru1nyMtJc5YKfHUC7Yvnh 65g08xP15MdX6nvzHa5RsrLy27telxfEc3IONrWejR+8fs+Iebqzq5Kba Y8XP3WtGJ149byHpG8p2oYAYdgiED17rZPPDl/XWq2O3uQf++gbP8B+8k c=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgAUKOhW/5RdJa1eg0ZUbga4OoIPD?= =?us-ascii?q?oFuIYVsAoE0OBQBAQEBAQEBZCeEQgEBBHkQAgEIDjgCHxElAgQOBQ4Gh30DEg6?= =?us-ascii?q?5Pg2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYahEKCPYFmLoQkBY1yiV0Bg?= =?us-ascii?q?xuBZm2GHYF1gWWHb4UxhyyHUgEeAUODZWqJKAc2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,339,1454976000"; d="p7s'?scan'208";a="248920869" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 15:25:59 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2FFPxh8023363 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 15:25:59 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 10:25:58 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 10:25:59 -0500 From: "Graham Bartlett (grbartle)" To: Yoav Nir Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCT0HkAAA9+PoAAKAIqgAACBo+AAANw9YAANxCAgAADjbcAAb7mf4A= Date: Tue, 15 Mar 2016 15:25:58 +0000 Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> In-Reply-To: <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.103] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3540900355_9953386" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 15:26:14 -0000 --B_3540900355_9953386 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Last night I noticed the following, https://community.akamai.com/docs/DOC-5289 It talks of various results when using a single packet to generate an amplification attack. (well worth a read..) As we discussed last week, all implementations that send multiple replies to a single SA_INIT would be broken in some form. Because of the impact of this (and these shocking results), I=B9d like to add the following words to the security considerations around retransmissions with respect to amplification attacks using SA_INIT / IKE_AUTH; "As described in RFC7296 Use of Retransmission Timers. For every pair of message it is the responsibility of the initiator to retransmit should a message be lost. A responder MUST only send a single reply to an SA_INIT or IKE_AUTH message and MUST never engage the retransmission mechanism, even if a reply is not received. This mitigates the chances that a response will become a victim of an amplification attack where a single packet is used to generate multiple replies." Thoughts? cheers On 06/03/2016 17:09, "Yoav Nir" wrote: >IMHO even in that case this is not an interesting attack. We should be >worried about amplification attacks where little traffic causes a lot of >traffic, not a case where I send a 200-byte packet which results in a >250-byte packet, and not even a 5 250-byte packets. Sending a request and >directing a server to send an entire movie in 4K quality using RTP in an >interesting amplification attack. Using a 10-Mbps uplink to generate >12-Mbps of traffic is not. > >Yoav --B_3540900355_9953386 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgBjhL w84VFRimAYTjodi6r53IjesaZQanjlrv1TMUAIwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE1MTUyNTU1WjANBgkqhkiG9w0BAQEFAASCAQBkw8m2 aAh1yDK1hGdR3g22ywUL+cWh7U7N8pUafO7vIYdhujzZ5fFA8vLGKqRYLD42G+/3lN2QYIzL VstLTWoGxklUG+Msv5chLH4Dgz1yrH+Q9NWtHB+X7dySSpdVUKgxBMnS0+61tPEOSfcaAARa jf1K90idx5h2oTwtXfobYmJ+PW/Sj3vCkepTXBRbxlrLaxMyMlOQi/FMm5HrZlAXaM3kAHx2 oSLTo6r58//wV2+uqXd1nKK3sVpgFsLnmgXXvdMb3o8FPn+xxZOsBJcVvGlZousP9MzRp4yL wZVvQsp3gjxWrMXcmK4s9TSJfTTuNJEy+yQZCGASieNaYWku --B_3540900355_9953386-- From nobody Tue Mar 15 08:55:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD35012DB81 for ; Tue, 15 Mar 2016 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NZFv4_OAzCBQ for ; Tue, 15 Mar 2016 08:55:40 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9E812DB60 for ; Tue, 15 Mar 2016 08:55:39 -0700 (PDT) Received: by mail-lb0-x235.google.com with SMTP id k12so28859632lbb.1 for ; Tue, 15 Mar 2016 08:55:39 -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-transfer-encoding; bh=bN4OkP3cajSXK9rF4d3vV/rEO+9Ltcybrjy5xLNWZfI=; b=r6uJSMCiI9AbPw0C/18beSygmohZSsIOyGE6TVzbg7XaDXhBPlVZ4ydnAvNpWnOUwu muBYO4kZ4q8Ks5fKC1T1QMVh8MK4LiIq3NNQ9zk0lIOA1WsUaG2AIcrlhwnDd+d3D6JX yKXsop8uusagUBaNPPqdz1QqrqlbUraSC8ksXklDrkLCSy6ppKBF+y2qZFnM6S4DQh2W JBaj02JSA3cSEzgBxkWz0FR2ZNKZ2nEHgpDw3WGpVHrnnAaKn25E6tVXl0QbtKKNKNcB NfqkL0deZ/SxA4M4B8C+b8ckU3saJrFFRhD6wOR1MKy1kSB2iWSw1oJwwf+kCIbqPzBA woyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=bN4OkP3cajSXK9rF4d3vV/rEO+9Ltcybrjy5xLNWZfI=; b=iYtBmnH3YxlVPamEjOEoNoTamzFrPi/7pV9FQNZYuRJd90DdlZ7v2nG98h10Ve0v6d 6VmTrtAWRQ/QbYw9oc7xcMhKdvOxSFhuFEK0HKS+w+FuxDK/EPztoPOfps5XEdP6+9qI Vimhk1S+culTmzmCQYx4XXMubs+NzQYmKNdgKTxBHRMeLVKBPOcEQKN9sH0hF79FqJqd JWz+gtHEFqnTkZOLXiPeXLlqgzZjdgjtF2t99jr5F73aE42KEiGRpQ3+LprItL7U8pGh ifLbzu257qqIBm8YmepkxaxZqD1dK7GiVArw72+HOoAJEb8Zk/16is1uwDjMTAXY9FzY DWZw== X-Gm-Message-State: AD7BkJLJx4gR7WcxP2E3jD6knRaqdzf+2hV8Drj5+GXkP+w7SalVcjcn0JeVRG7qRlPpJQ== X-Received: by 10.25.209.83 with SMTP id i80mr10993428lfg.74.1458057335838; Tue, 15 Mar 2016 08:55:35 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f7sm4371138lfg.19.2016.03.15.08.55.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 08:55:34 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Yoav Nir" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> Date: Tue, 15 Mar 2016 18:55:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit 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: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 15:55:43 -0000 Hi Graham, I don't think it is necessary, since RFC7296 already has the requirement in Section 2.1: For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request. So, such implementations are obviously broken, and I don't think we need to duplicate the RFC2119 requirements from IKEv2 spec. If you think it's worth to emphasize this requirement, then, I think, it must be re-worded without using RFC2119 words, and must refer to the RFC7296 as the source of requirement. Something like that: To prevent amplification attacks the Responder must retransmit the response message only if it receives a retransmitted request from Initiator, and must not do it under any other circumstances. Note, that this behaviour is already prescribed in Section 2.1 of RFC7296. Regards, Valery. ----- Original Message ----- From: "Graham Bartlett (grbartle)" To: "Yoav Nir" Cc: "Valery Smyslov" ; "Paul Wouters" ; Sent: Tuesday, March 15, 2016 6:25 PM Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Hi Last night I noticed the following, https://community.akamai.com/docs/DOC-5289 It talks of various results when using a single packet to generate an amplification attack. (well worth a read..) As we discussed last week, all implementations that send multiple replies to a single SA_INIT would be broken in some form. Because of the impact of this (and these shocking results), I¹d like to add the following words to the security considerations around retransmissions with respect to amplification attacks using SA_INIT / IKE_AUTH; "As described in RFC7296 Use of Retransmission Timers. For every pair of message it is the responsibility of the initiator to retransmit should a message be lost. A responder MUST only send a single reply to an SA_INIT or IKE_AUTH message and MUST never engage the retransmission mechanism, even if a reply is not received. This mitigates the chances that a response will become a victim of an amplification attack where a single packet is used to generate multiple replies." Thoughts? cheers On 06/03/2016 17:09, "Yoav Nir" wrote: >IMHO even in that case this is not an interesting attack. We should be >worried about amplification attacks where little traffic causes a lot of >traffic, not a case where I send a 200-byte packet which results in a >250-byte packet, and not even a 5 250-byte packets. Sending a request and >directing a server to send an entire movie in 4K quality using RTP in an >interesting amplification attack. Using a 10-Mbps uplink to generate >12-Mbps of traffic is not. > >Yoav From nobody Tue Mar 15 17:52:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9A412DE69 for ; Tue, 15 Mar 2016 17:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 Jtm5TPgAM4IR for ; Tue, 15 Mar 2016 17:52:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 9C29712DE8B for ; Tue, 15 Mar 2016 17:52:08 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2G0pugC003300 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Mar 2016 02:51:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2G0puAs015879; Wed, 16 Mar 2016 02:51:56 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22248.44588.71321.602201@fireball.acr.fi> Date: Wed, 16 Mar 2016 02:51:56 +0200 From: Tero Kivinen To: "Graham Bartlett \(grbartle\)" In-Reply-To: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 12 min Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 00:52:12 -0000 Graham Bartlett (grbartle) writes: > Hi >=20 > Last night I noticed the following, >=20 > https://community.akamai.com/docs/DOC-5289 >=20 > It talks of various results when using a single packet to generate an= > amplification attack. (well worth a read..) And it does NOT talk about IKEv2 at all. The whole text is only covering IKEv1, even if they claim to cover both IKE and IKEv2. RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies completely different transmission policy, i.e. it does not use what is defined in the RFC2408. This paper is just completely wrong and the conclusions for it is also completely wrong for IKEv2. It should really say that everybody simply should DISABLE IKEv1 and only enable IKEv2 in their configuration and that should fix the issue.= The paper does not even have any kind of contact information, so there is no way to send in comments to try to get them to understand that their paper is completely wrong when related to the IKEv2. > As we discussed last week, all implementations that send multiple rep= lies > to a single SA=5FINIT would be broken in some form. Because of the im= pact of > this (and these shocking results), I=B9d like to add the following wo= rds to > the security considerations around retransmissions with respect to > amplification attacks using SA=5FINIT / IKE=5FAUTH; In their paper there was not asingle IKE=5FSA=5FINIT nor IKE=5FAUTH pac= kets sent. All the frames used Exchange Type of 2 (Identity Protect =3D=3D IKEv1 Main Mode), not the Exchange types 32-37 (IKE=5FSA=5FINIT, IKE=5F= AUTH etc).=20 > "As described in RFC7296 Use of Retransmission Timers. For every pair= of > message it is the responsibility of the initiator to retransmit shoul= d a > message be lost. A responder MUST only send a single reply to an SA=5F= INIT > or IKE=5FAUTH message and MUST never engage the retransmission mechan= ism, > even if a reply is not received. This mitigates the chances that a > response will become a victim of an amplification attack where a sing= le > packet is used to generate multiple replies." This requirement is already in the RFC7296 section 2.1, and there is no point of say it again here. Even if we say it here, it does not change the retransmissions for the IKEv1, as this draft does not cover IKEv1. What we could say in the DDoS draft is to add saying that IKEv1 protocol is obsoleted, and will be common avenue for the DDoS attacks, and because of that it MUST be disabled. Or perhaps we need the IKEv1 considered harmful draft / ikev1-diediediediedie...=20 --=20 kivinen@iki.fi From nobody Tue Mar 15 18:10:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7012DEC1 for ; Tue, 15 Mar 2016 18:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HK_NAME_FM_DR=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r_YydYibN3eb for ; Tue, 15 Mar 2016 18:10:35 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF23112DEBD for ; Tue, 15 Mar 2016 18:10:34 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id k12so38124417lbb.1 for ; Tue, 15 Mar 2016 18:10:34 -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; bh=Kv0W6gqn3UVMYLkl+bW+7B+cBwFLui+KO2D2SaK0Ipc=; b=j5zqRlga98xYsR9imW+k6QMTS8f6OdKzYGwU73+mGVLzMbDHGRsoovUnRgmTcbItJ5 iDfdRiH8MkmmXn8dV4E4I57kw1+jEWoNCHd87miJAtR5Ucn7PsrbfYaIbyFvxFjKVU4M vgJECG0nTvES8bAuBI0LKf032nr2zDy0ow8N0fGiLcq6L1na0sbRSmLG4lMVXf1UOcbC B+U4IaWUS5qO/j5Yn+97fEMCWkS6m7JtpcvKxVacXS6Ffyefj9k2ciDEn/qPsczCRcn7 uYI+qmei0x4sriGH3W6cOZzV7ao4k+PbAFGpr/ZGlCtFnoQtDForDWg6X189/fJiesge qQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Kv0W6gqn3UVMYLkl+bW+7B+cBwFLui+KO2D2SaK0Ipc=; b=PsExXl2ZcYH+sWGJrSxYvDWWHnHPunx7i0osQJ68knq6MN9ngbc16fKTNVcy4DXIEB AUgFT5Vg4PyHHF0dIpvmYQSfHqW1HsBiEDXQ0WaZMrY1RcW4AZ1L1VX0KqvZvr4UFsi9 BZbVDbeCUqV4xkndIAmxxDaLvNWwpcwWOYSOJDPjYo1ERSZmLLDUKGHjJwgS8TmYvGTD JiJcT9Q3JAOjtKW0iq//ykcOQ9HVMadcEqvflUbYK3z5jZRVdI4lJYFynTaNRk4KiNVq l3yhX37dr4S0AVkdMsdvzhQ0ia5hEuZhGkpIZgGiPGC1nTH4Q8RuKWxcTzCEvd+OfM+m ggPQ== X-Gm-Message-State: AD7BkJJFie1FEzZFu/LC2Phzq8wvQwcQB5YuoKM09rYPOY07HRjVgO/APk1NGg4kFSOamW1gpG4uyhD8BxVcww== MIME-Version: 1.0 X-Received: by 10.112.211.168 with SMTP id nd8mr332642lbc.116.1458090632960; Tue, 15 Mar 2016 18:10:32 -0700 (PDT) Received: by 10.25.35.88 with HTTP; Tue, 15 Mar 2016 18:10:32 -0700 (PDT) In-Reply-To: <22248.44588.71321.602201@fireball.acr.fi> References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> Date: Wed, 16 Mar 2016 06:40:32 +0530 Message-ID: From: "Dr. Karan Verma" To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11c3bc4e3a6084052e202e18 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , "Graham Bartlett \(grbartle\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 01:10:37 -0000 --001a11c3bc4e3a6084052e202e18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes, it's right +1 On Wed, Mar 16, 2016 at 6:21 AM, Tero Kivinen wrote: > Graham Bartlett (grbartle) writes: > > Hi > > > > Last night I noticed the following, > > > > https://community.akamai.com/docs/DOC-5289 > > > > It talks of various results when using a single packet to generate an > > amplification attack. (well worth a read..) > > And it does NOT talk about IKEv2 at all. The whole text is only > covering IKEv1, even if they claim to cover both IKE and IKEv2. > > RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers > IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies > completely different transmission policy, i.e. it does not use what is > defined in the RFC2408. > > This paper is just completely wrong and the conclusions for it is also > completely wrong for IKEv2. > > It should really say that everybody simply should DISABLE IKEv1 and > only enable IKEv2 in their configuration and that should fix the issue. > > The paper does not even have any kind of contact information, so there > is no way to send in comments to try to get them to understand that > their paper is completely wrong when related to the IKEv2. > > > As we discussed last week, all implementations that send multiple repli= es > > to a single SA_INIT would be broken in some form. Because of the impact > of > > this (and these shocking results), I=C2=B9d like to add the following w= ords to > > the security considerations around retransmissions with respect to > > amplification attacks using SA_INIT / IKE_AUTH; > > In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets > sent. All the frames used Exchange Type of 2 (Identity Protect =3D=3D > IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH > etc). > > > "As described in RFC7296 Use of Retransmission Timers. For every pair o= f > > message it is the responsibility of the initiator to retransmit should = a > > message be lost. A responder MUST only send a single reply to an SA_INI= T > > or IKE_AUTH message and MUST never engage the retransmission mechanism, > > even if a reply is not received. This mitigates the chances that a > > response will become a victim of an amplification attack where a single > > packet is used to generate multiple replies." > > This requirement is already in the RFC7296 section 2.1, and there is > no point of say it again here. Even if we say it here, it does not > change the retransmissions for the IKEv1, as this draft does not cover > IKEv1. > > What we could say in the DDoS draft is to add saying that IKEv1 > protocol is obsoleted, and will be common avenue for the DDoS attacks, > and because of that it MUST be disabled. > > Or perhaps we need the IKEv1 considered harmful draft / > ikev1-diediediediedie... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 Best Regards Dr. Karan Verma Assistant Professor Computer Science and Engineering Dept. Central University Rajasthan, India Website: www.drkaranverma.com Phone: +917568169258 --001a11c3bc4e3a6084052e202e18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes, it's right=C2=A0

+1=C2=A0

On Wed, Ma= r 16, 2016 at 6:21 AM, Tero Kivinen <kivinen@iki.fi> wrote:
=
Graham Bartlett (grbartle) = writes:
> Hi
>
> Last night I noticed the following,
>
> https://community.akamai.com/docs/DOC-5289
>
> It talks of various results when using a single packet to generate an<= br> > amplification attack. (well worth a read..)

And it does NOT talk about IKEv2 at all. The whole text is only
covering IKEv1, even if they claim to cover both IKE and IKEv2.

RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
completely different transmission policy, i.e. it does not use what is
defined in the RFC2408.

This paper is just completely wrong and the conclusions for it is also
completely wrong for IKEv2.

It should really say that everybody simply should DISABLE IKEv1 and
only enable IKEv2 in their configuration and that should fix the issue.

The paper does not even have any kind of contact information, so there
is no way to send in comments to try to get them to understand that
their paper is completely wrong when related to the IKEv2.

> As we discussed last week, all implementations that send multiple repl= ies
> to a single SA_INIT would be broken in some form. Because of the impac= t of
> this (and these shocking results), I=C2=B9d like to add the following = words to
> the security considerations around retransmissions with respect to
> amplification attacks using SA_INIT / IKE_AUTH;

In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packet= s
sent. All the frames used Exchange Type of 2 (Identity Protect =3D=3D
IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
etc).

> "As described in RFC7296 Use of Retransmission Timers. For every = pair of
> message it is the responsibility of the initiator to retransmit should= a
> message be lost. A responder MUST only send a single reply to an SA_IN= IT
> or IKE_AUTH message and MUST never engage the retransmission mechanism= ,
> even if a reply is not received. This mitigates the chances that a
> response will become a victim of an amplification attack where a singl= e
> packet is used to generate multiple replies."

This requirement is already in the RFC7296 section 2.1, and there is=
no point of say it again here. Even if we say it here, it does not
change the retransmissions for the IKEv1, as this draft does not cover
IKEv1.

What we could say in the DDoS draft is to add saying that IKEv1
protocol is obsoleted, and will be common avenue for the DDoS attacks,
and because of that it MUST be disabled.

Or perhaps we need the IKEv1 considered harmful draft /
ikev1-diediediediedie...
--
kivinen@iki.fi

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



--
=
Best Regards=C2=A0

Dr. Karan Verma=C2=A0
Assistant Professor=C2=A0=C2=A0
Computer Science and Engineering Dept.
<= div dir=3D"ltr" style=3D"font-size:small">
Central University Rajasthan= , India=C2=A0
Website:=C2=A0www.drkaranverma.com
--001a11c3bc4e3a6084052e202e18-- From nobody Wed Mar 16 02:19:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67B612D77F for ; Wed, 16 Mar 2016 02:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 veNs2Mp50w1e for ; Wed, 16 Mar 2016 02:19:21 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA2412D6B0 for ; Wed, 16 Mar 2016 02:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8701; q=dns/txt; s=iport; t=1458119961; x=1459329561; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Piij1D+hoO44/7CfmZo2V2O79BWVUvlgT0SBG9CjygQ=; b=akxg13mmh5E7sXXq/qLKu42YFH7/r3uZ6RSo/dP59CI7hAeJLoi/40XQ ed648HgHQijvGqoT+dtOTxfa+fLYFGOq9pd5RJTEMzdAfI2KTZjL7mlD+ 6O7bTTLBOG8DjZvJq+QjeUixaVOHKgIDN280GqmQs2sJNtGqh9rJEaY0T Y=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAgBBJOlW/4QNJK1VCYNGU24Gt22CD?= =?us-ascii?q?w6BbiGFbAIlgRU4FAEBAQEBAQFkJ4RCAQEEeRACAQhEAgIwJQIEDgUOBogTDpI?= =?us-ascii?q?MnQ8Gj2IBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASGHoREhBMKAQEzgmSBQAWXU?= =?us-ascii?q?QGDG4FmbYgSgWWHb4Uxjn4BHgFDg2VqiSgHAhcdfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,344,1454976000"; d="p7s'?scan'208";a="249093388" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 09:19:19 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2G9JJQS008127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 09:19:19 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 04:19:19 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Wed, 16 Mar 2016 04:19:19 -0500 From: "Graham Bartlett (grbartle)" To: Tero Kivinen Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQCT0HkAAA9+PoAAKAIqgAACBo+AAANw9YAANxCAgAADjbcAAb7mf4AAE8SVAAARuBCA Date: Wed, 16 Mar 2016 09:19:19 +0000 Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> In-Reply-To: <22248.44588.71321.602201@fireball.acr.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.103] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3540964757_11493555" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 09:19:24 -0000 --B_3540964757_11493555 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi Tero There=A1=AFs many references to IKEv2 in the paper. E.g. "Figure 1: Zmap scan using our IKEv2 payload=A1=B1.. I=A1=AFve managed to track the author down and made contact. I=A1=AFll sync you in on a mail and hopefully we can verify what was exactly was used. All I would ask is - if many IKEv2 implementation are vulnerable to an amplification attack, I feel it would be prudent to add some words to remind implementors of the risk. cheers On 16/03/2016 00:51, "Tero Kivinen" wrote: >Graham Bartlett (grbartle) writes: >> Hi >>=20 >> Last night I noticed the following, >>=20 >> https://community.akamai.com/docs/DOC-5289 >>=20 >> It talks of various results when using a single packet to generate an >> amplification attack. (well worth a read..) > >And it does NOT talk about IKEv2 at all. The whole text is only >covering IKEv1, even if they claim to cover both IKE and IKEv2. > >RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers >IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies >completely different transmission policy, i.e. it does not use what is >defined in the RFC2408. > >This paper is just completely wrong and the conclusions for it is also >completely wrong for IKEv2. > >It should really say that everybody simply should DISABLE IKEv1 and >only enable IKEv2 in their configuration and that should fix the issue. > >The paper does not even have any kind of contact information, so there >is no way to send in comments to try to get them to understand that >their paper is completely wrong when related to the IKEv2. > >> As we discussed last week, all implementations that send multiple >>replies >> to a single SA_INIT would be broken in some form. Because of the impact >>of >> this (and these shocking results), I=A9=F6d like to add the following words >>to >> the security considerations around retransmissions with respect to >> amplification attacks using SA_INIT / IKE_AUTH; > >In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets >sent. All the frames used Exchange Type of 2 (Identity Protect =3D=3D >IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH >etc).=20 > >> "As described in RFC7296 Use of Retransmission Timers. For every pair of >> message it is the responsibility of the initiator to retransmit should a >> message be lost. A responder MUST only send a single reply to an SA_INIT >> or IKE_AUTH message and MUST never engage the retransmission mechanism, >> even if a reply is not received. This mitigates the chances that a >> response will become a victim of an amplification attack where a single >> packet is used to generate multiple replies." > >This requirement is already in the RFC7296 section 2.1, and there is >no point of say it again here. Even if we say it here, it does not >change the retransmissions for the IKEv1, as this draft does not cover >IKEv1. > >What we could say in the DDoS draft is to add saying that IKEv1 >protocol is obsoleted, and will be common avenue for the DDoS attacks, >and because of that it MUST be disabled. > >Or perhaps we need the IKEv1 considered harmful draft / >ikev1-diediediediedie... >--=20 >kivinen@iki.fi --B_3540964757_11493555 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgoyMB FAHSWC+hrOIxQViHBqFyMQSM4GqvZHihICqeIWQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE2MDkxOTE3WjANBgkqhkiG9w0BAQEFAASCAQBfyLKW iJZqwTPXqxCr595nOaOGuNpGbCmpjaBdvdUVaGkjX3EKjqTGekEHevZH0Ru8U4lGVAZ6OXlr pCnsJ3MpDsZTXV0abRrEciAo/uiyE9n32qFf+MezS2AlJsj+1tmSqlB5KvG8W0F6khN8b6nV xtHKAaNlDGrWK7raNkJlmsOF1rTiOHE9QwBXGEnRHLWMUDUmk+D/Edz3btxOoZ1vUEr7QoaC klj6cv23jf0mKr05hEzP6ffYASvJvzGiEwfmqxWaYGRzAFWTBQ7bo3QR7pj6xO8070Lr3te8 g71p5PVL4Gc4Ul9JAiIDeI+9llqsVtAUVpiHos1L27J0a2P9 --B_3540964757_11493555-- From nobody Wed Mar 16 05:28:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BC012D766 for ; Wed, 16 Mar 2016 05:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 NS_ThV_aKWp7 for ; Wed, 16 Mar 2016 05:27:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 389E712D5AC for ; Wed, 16 Mar 2016 05:27:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQ9k44TmLz1Jv; Wed, 16 Mar 2016 13:27:56 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Vn3ejuq2j6jS; Wed, 16 Mar 2016 13:27:55 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 13:27:55 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id C11CB603BBA1; Wed, 16 Mar 2016 08:27:54 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca C11CB603BBA1 References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> Mime-Version: 1.0 (1.0) In-Reply-To: <22248.44588.71321.602201@fireball.acr.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Wed, 16 Mar 2016 08:27:44 -0400 To: Tero Kivinen Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , "Graham Bartlett \(grbartle\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:28:02 -0000 >=20 > Or perhaps we need the IKEv1 considered harmful draft / > ikev1-diediediediedie...=20 I don't think that will help. I've seen how reluctant people are to change t= heir 10 year old working VPN.=20 IKEv1 is dying pretty quickly now, thanks to mobile phones. But it will be a= nother year or two. Right now, a diediedie document won't help me remove or disable IKEv1 code. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 16 05:39:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4191712D943 for ; Wed, 16 Mar 2016 05:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TXJUR7cMcTs7 for ; Wed, 16 Mar 2016 05:39:35 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AE012D791 for ; Wed, 16 Mar 2016 05:39:09 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p65so70502324wmp.0 for ; Wed, 16 Mar 2016 05:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OBS9Zsw22ZOQUEBFlJz5ieYRkMbZTXr5tt8WZgMw0rE=; b=u9HALFQTYdpsKKmLz6AMt/pX7qpw5ub0Ylfd44wosnjpPwuFa2TFIuEWbfDYZ2rBWc /4tuiNWUgAOUlAMNezO40IQGgL7xNU0Vlh14glYPnV3HTKWX7h/g7ArxbOs/NT+71VN1 FNSACFH6RMO7NqXmU6BW454A4vWYA0qWz8GOPureWBfQTv33IzQLzlWNw8SZSNSNHmK0 q+jTec/mQFre3+3uWSvPRf+NE9k98GuSPuulEEq1xef3G58S4iQ9mwUEL3UIEhZKobgM KtfQO8Pmxtm7hw/QYI4jJjcxTOdU0IJikH1ciWS6DfvvVv04qZqwdgHUOmAkm8otM3QR 9x7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OBS9Zsw22ZOQUEBFlJz5ieYRkMbZTXr5tt8WZgMw0rE=; b=h5r3BDJYGZ//x74vwc/vFsyrUvsitJy+Ti4N3ATGO2FO+184e6RdKd7jm+SLNXpkHQ +/yCrcBkThWh87au9p2OGl9CqIUG2aP2rgZF0KfP84fhFfMYDDmtnVySFHHOGRDKhD++ Y0LN127G/SGZV1EpZMasD7V8KsMK2VBJKcIIByI028HbNCc3K2ezlH0NEYlhLKsbLUG2 L1byNpEvTYHRAp1oYC43aV71U6nW+64JSEmAMe89muU8d2dWmKTlWFFy89KMND0oimif Md/CS3FVMD4LrLR9YFH5YliCQ1T83p3TQkbOF+UA7DNx9Zl5lpZdHaJ7NokmNZSC1j8o ckZg== X-Gm-Message-State: AD7BkJJ9L5UoJ3LdJesWTI5fJh6Djat6BW6FMSRqFu1r2HYEx86UwtV2y+grVhb6jEZAAg== X-Received: by 10.28.186.196 with SMTP id k187mr3056096wmf.17.1458131947991; Wed, 16 Mar 2016 05:39:07 -0700 (PDT) Received: from [172.24.249.100] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 77sm25485109wmp.18.2016.03.16.05.39.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 05:39:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Wed, 16 Mar 2016 14:39:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34C0B4A8-EDB8-4FD0-998D-B35A79245FF5@gmail.com> References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , "Graham Bartlett \(grbartle\)" , Tero Kivinen Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:39:40 -0000 > On 16 Mar 2016, at 2:27 PM, Paul Wouters wrote: >=20 >=20 >>=20 >> Or perhaps we need the IKEv1 considered harmful draft / >> ikev1-diediediediedie...=20 >=20 > I don't think that will help. I've seen how reluctant people are to = change their 10 year old working VPN.=20 >=20 > IKEv1 is dying pretty quickly now, thanks to mobile phones. Really? Granted, it=E2=80=99s been a couple of years since I=E2=80=99ve = checked the VPN capabilities of an iPhone, but I remember it having L2TP = (using IKEv1) and XAuth (A Cisco extension to IKEv1). We have some = people from Apple in the working group who are talking about IKEv2 on = the phone, but I don=E2=80=99t think they=E2=80=99re removing the = support for L2TP or XAuth. Android IIRC also has the L2TP with IKEv1. Not sure what else. Windows Mobile? You can add your own, or you have the usual Windows = PPTP, L2TP (again with IKEv1) and IKEv2. Who=E2=80=99s killing IKEv1? Yoav From nobody Wed Mar 16 05:55:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABF412D942 for ; Wed, 16 Mar 2016 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 J5sdjsTCuMSJ for ; Wed, 16 Mar 2016 05:55:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 0D98512D573 for ; Wed, 16 Mar 2016 05:55:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQBKR2y70z21G; Wed, 16 Mar 2016 13:55:07 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OA4hTP7WteEE; Wed, 16 Mar 2016 13:55:05 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 13:55:04 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 06D7D603BBA1; Wed, 16 Mar 2016 08:54:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 06D7D603BBA1 References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <34C0B4A8-EDB8-4FD0-998D-B35A79245FF5@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <34C0B4A8-EDB8-4FD0-998D-B35A79245FF5@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Wed, 16 Mar 2016 08:54:48 -0400 To: Yoav Nir Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , "Graham Bartlett \(grbartle\)" , Tero Kivinen Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:55:11 -0000 These are all backwards compatible things. The cool things are happening at I= KEv2, and the management tools and required features will push users to v2. S= ure static v1 site to site will remain in place until 3des or hmac-md5 is br= oken (and they'd still not upgrade) Just make sure people don't implement support for tcp in v1 :) Sent from my iPhone > On Mar 16, 2016, at 08:39, Yoav Nir wrote: >=20 >=20 >> On 16 Mar 2016, at 2:27 PM, Paul Wouters wrote: >>=20 >>=20 >>>=20 >>> Or perhaps we need the IKEv1 considered harmful draft / >>> ikev1-diediediediedie... >>=20 >> I don't think that will help. I've seen how reluctant people are to chang= e their 10 year old working VPN.=20 >>=20 >> IKEv1 is dying pretty quickly now, thanks to mobile phones. >=20 > Really? Granted, it=E2=80=99s been a couple of years since I=E2=80=99ve c= hecked the VPN capabilities of an iPhone, but I remember it having L2TP (usi= ng IKEv1) and XAuth (A Cisco extension to IKEv1). We have some people from A= pple in the working group who are talking about IKEv2 on the phone, but I do= n=E2=80=99t think they=E2=80=99re removing the support for L2TP or XAuth. >=20 > Android IIRC also has the L2TP with IKEv1. Not sure what else. >=20 > Windows Mobile? You can add your own, or you have the usual Windows PPTP,= L2TP (again with IKEv1) and IKEv2. >=20 > Who=E2=80=99s killing IKEv1? >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 16 06:23:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5212D969 for ; Wed, 16 Mar 2016 06:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UAmbl8bvMmbE for ; Wed, 16 Mar 2016 06:23:04 -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 4547312D968 for ; Wed, 16 Mar 2016 06:23:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C5AA3200A3; Wed, 16 Mar 2016 09:25:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DE71963755; Wed, 16 Mar 2016 09:23:02 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22248.44588.71321.602201@fireball.acr.fi> References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , "Graham Bartlett \(grbartle\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 13:23:06 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > What we could say in the DDoS draft is to add saying that IKEv1 > protocol is obsoleted, and will be common avenue for the DDoS attacks, > and because of that it MUST be disabled. > Or perhaps we need the IKEv1 considered harmful draft / > ikev1-diediediediedie... Yes, I would say so. I'd even suggest that maybe it needs a CVE against products that have IKEv1 turned on by default. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVuleNICLcPvd0N1lAQIo0Af/QNkMmHwwIn48r5QpnMilqPI3obO2ifKX jhtHtkBSWz3KTQRkoTIsxGFu3FKGD2kkT0YCZT7jasuGQq0PVT8tW6U3OXKyxGw8 NFRXzRPnioEN137LPQ092RC9xd63xSMsGzgnXw6Vd2m2i3P1C4p+XMAxI7eel3ZI hkpSBBtLIeWfKS0ziEPp+XQFh+BxhH2haKwR78N7VIlUpwwqgFlQSsOjTIKH2yeq zJxj9zWYhdBC0V++JDPx/NrABJqG8vj/hwc3OczF1WgOmGrEEtgvnT4Cy/HkEXTS DPSjXjVUuHN/JFiD/f4SdPpwUVDITn49bzayzy2189/irIqOXLbGFw== =VoLk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 16 07:21:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E950212D979 for ; Wed, 16 Mar 2016 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com 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 U8Zss6-dlcob for ; Wed, 16 Mar 2016 07:21:54 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D8512D5BB for ; Wed, 16 Mar 2016 07:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GmESqsIZMtWecoZbw+Tmq8iA30eHL5bpPv6eQyEMREk=; b=wIy0Dm++c9R2u+5n6rZBdsZ09SiYlP9cW0yMnTNEY81atJskc+0O4AtEwTS0Rn7et02r8r1ixRkAHakJphSagrKq/06fRJEAtvO864kPi83oTaLQLsx3JvFKd+9qNQ0fRb/Ckb3tB9yv8ubS7dayW9brvLD/i4g4rxINspml5Eo= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0367.namprd09.prod.outlook.com (10.160.247.21) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 16 Mar 2016 14:21:53 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0427.021; Wed, 16 Mar 2016 14:21:53 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AdFzz6vWEN1mpUdbReie8Bmkunv/FQLvnIHw Date: Wed, 16 Mar 2016 14:21:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 817d58ae-8f5e-45f4-0954-08d34da6529f x-microsoft-exchange-diagnostics: 1; DM2PR09MB0367; 5:fYNJgJ5kmKt6FLZCbXU05IdKSL3Jcnq/yqc3iqGH6l7rfKdTZDuJCzMxdPHCONJL8EjvkV7Uh7pQmkKZLrQBGd7DpCu/iwYYurJ0qWIoyNlk7fPzoUh7958x7uWG7WGZmH8CM6+xsMYfalqhyTonVA==; 24:2YuNX6I3GVjVfIcS35HNO6Sr/gy0e6CjWCttprfcASI+bLpyR1Ybw94nZw5cSX6MXv6cQn0oEqAPWYX7uM4fvT8OVcMihxPb5OFe7gGCw3Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0367; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR09MB0367; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0367; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(164054003)(33656002)(92566002)(19580405001)(19580395003)(3900700001)(5008740100001)(81166005)(3660700001)(11100500001)(3280700002)(1220700001)(2906002)(230783001)(122556002)(15975445007)(99286002)(2900100001)(189998001)(107886002)(586003)(76576001)(5003600100002)(5002640100001)(10400500002)(50986999)(54356999)(450100001)(87936001)(86362001)(110136002)(77096005)(1096002)(74316001)(6116002)(5004730100002)(102836003)(3846002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0367; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 14:21:53.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0367 Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:21:58 -0000 This is just a friendly reminder that the WGLC on draft-ietf-ipsecme-ddos-p= rotection-04.txt ends on March 18th, 2016. The list discussion has been good on the draft. Thank you to everyone that = commented so far. If you have any additional comments, please send them to the list by the en= d of the day UTC on Friday. Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Tuesday, March 01, 2016 10:34 AM > To: IPsecME WG > Subject: WGLC on draft-ietf-ipsecme-ddos-protection-04 >=20 > All: >=20 > With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe = the > draft is shaping up nicely, but needs additional review. To that end, thi= s > message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme- > ddos-protection-04. >=20 > The version to be reviewed is https://tools.ietf.org/id/draft-ietf-ipsecm= e- > ddos-protection-04.txt. >=20 > Please send your comments, questions, and edit proposals to the WG mail > list until March 18, 2015. If you believe that the document is ready to = be > submitted to the IESG for consideration as a Standards Track RFC please s= end > a short message stating this. >=20 > Best Regards, > Dave From nobody Wed Mar 16 08:53:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D625B12D65D for ; Wed, 16 Mar 2016 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 lSxgucxTIWfY for ; Wed, 16 Mar 2016 08:53:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 6910012D724 for ; Wed, 16 Mar 2016 08:53:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQGGm4XRdz21f; Wed, 16 Mar 2016 16:53:04 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id M0z20I_MQC6t; Wed, 16 Mar 2016 16:53:03 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 16:53:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D0372603BBA1; Wed, 16 Mar 2016 11:53:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D0372603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CE8EEA3C7; Wed, 16 Mar 2016 11:53:02 -0400 (EDT) Date: Wed, 16 Mar 2016 11:53:02 -0400 (EDT) From: Paul Wouters To: Michael Richardson In-Reply-To: <11877.1458134582@obiwan.sandelman.ca> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , "Graham Bartlett \(grbartle\)" , Tero Kivinen , Yoav Nir Subject: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:53:10 -0000 On Wed, 16 Mar 2016, Michael Richardson wrote: > Tero Kivinen wrote: > > What we could say in the DDoS draft is to add saying that IKEv1 > > protocol is obsoleted, and will be common avenue for the DDoS attacks, > > and because of that it MUST be disabled. > > > Or perhaps we need the IKEv1 considered harmful draft / > > ikev1-diediediediedie... > > Yes, I would say so. > > I'd even suggest that maybe it needs a CVE against products that have IKEv1 > turned on by default. No, because it is perfectly possible to implement IKEv1 without this problem. Libreswan is moving towards that, see: https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html Paul From nobody Wed Mar 16 08:55:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C1C12D574 for ; Wed, 16 Mar 2016 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 WdYFjc1gWwBw for ; Wed, 16 Mar 2016 08:55:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5F6E012D532 for ; Wed, 16 Mar 2016 08:55:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQGKh5lVDz22l; Wed, 16 Mar 2016 16:55:36 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MeAXe44A4HXB; Wed, 16 Mar 2016 16:55:36 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 16:55:35 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 30244603BBA1; Wed, 16 Mar 2016 11:55:35 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 30244603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2BDD3A3C7; Wed, 16 Mar 2016 11:55:35 -0400 (EDT) Date: Wed, 16 Mar 2016 11:55:35 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <34C0B4A8-EDB8-4FD0-998D-B35A79245FF5@gmail.com> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <34C0B4A8-EDB8-4FD0-998D-B35A79245FF5@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:55:39 -0000 On Wed, 16 Mar 2016, Yoav Nir wrote: > Really? Granted, it’s been a couple of years since I’ve checked the VPN capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and XAuth (A Cisco extension to IKEv1). We have some people from Apple in the working group who are talking about IKEv2 on the phone, but I don’t think they’re removing the support for L2TP or XAuth. Apple is pretty aggressively pushing IKEv2 (Thanks Tommy!) > Android IIRC also has the L2TP with IKEv1. Not sure what else. > > Windows Mobile? You can add your own, or you have the usual Windows PPTP, L2TP (again with IKEv1) and IKEv2. > > Who’s killing IKEv1? What I meant was in the last two years, the switch has been to have IKEv2 be the "current default VPN" and IKEv1 be the "legacy VPN". Note Windows Mobile did not have PPTP or L2TP until a few months ago, when they re-added it :( Paul From nobody Wed Mar 16 09:46:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69512D77C for ; Wed, 16 Mar 2016 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4GZwC1v1qq3I for ; Wed, 16 Mar 2016 09:46:18 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C39412D73C for ; Wed, 16 Mar 2016 09:46:18 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id h198so23632263lfh.0 for ; Wed, 16 Mar 2016 09:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=AVzzSxu3nN5IlCc1JZnia1pPvsOwNk7wd5PuOG27C4s=; b=TftcbjosfozYdQptRxajc86hemQZ+Y4GooD038LikfdTR760WxfV0MeGhYtKqBJplj yTSJ/GN1vqBR4GEjoglMzV1LWxQnUcrCJUYTILcyWGDQnLzPu7BK6mZX4SJzAMd4zs8w FV253bSeCb9RrazYgLsWyXdt141LFxOVXYC4jOb/gH+XOPrPj/PwA0ZUgU1s3eN4ZBB3 Xz69+CsVugMA4wMgFA+1PCenyLshPA8GRPC0jKFAQnaFu8QmfCUvdEEU48SrmmcDgGv6 4s/YDFNmOrdTaqtshQvXiMJjrPn95bhgxy/uMJv8QaeHQ5+1huRIEcIswJHjcjtqO1gn ediA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=AVzzSxu3nN5IlCc1JZnia1pPvsOwNk7wd5PuOG27C4s=; b=Xg3AtJA1SNJ0C2N0hsfCY+Pg/qAKgHs1bRvgaWnMRp7dj7tdjD5IFbGvZrOQsC4/4u 29yKbFRzJ65Ef3VJwp4IJu3WUVnLNi75NhJoNUv2NX3w+xl+7Binn0EF8wQtl2RGI6Cu ABgNJVwn8XyFG0+waS6HAgjPuxDw3HtXf/j5NWMWNnmJ5P9DeClphm8HW8690tJms8te 7O1t6lzKRPE6zWHXCKMU+2xdPKL5a7Bt+06sgpSuOayx2Dd9QGNBp0QvTJArADi7FsWH vFuu6hcJG4klAY2VNB7qAgAsaAtNJVH9TjJ4eJi42MBEJIjUx4Vp34ajhkohz64P28Rf 3zjg== X-Gm-Message-State: AD7BkJKk6Y021W3bErC7NLo5T7uSHT+XDZJxw1rajy+iKgwQ4dARwE0gvU1JY0ku7wvvUg== X-Received: by 10.25.134.70 with SMTP id i67mr1477217lfd.90.1458146776477; Wed, 16 Mar 2016 09:46:16 -0700 (PDT) Received: from chichi (ppp83-237-35-107.pppoe.mtu-net.ru. [83.237.35.107]) by smtp.gmail.com with ESMTPSA id un6sm668445lbb.18.2016.03.16.09.46.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 09:46:15 -0700 (PDT) Message-ID: <744900CC32EC4D9FA505C2FA2433F31F@chichi> From: "Valery Smyslov" To: "Paul Wouters" , "Michael Richardson" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> In-Reply-To: Date: Wed, 16 Mar 2016 19:46:10 +0300 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, "Graham Bartlett \(grbartle\)" , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:46:20 -0000 Hi Paul, > On Wed, 16 Mar 2016, Michael Richardson wrote: >> Tero Kivinen wrote: >> > What we could say in the DDoS draft is to add saying that IKEv1 >> > protocol is obsoleted, and will be common avenue for the DDoS attacks, >> > and because of that it MUST be disabled. >> >> > Or perhaps we need the IKEv1 considered harmful draft / >> > ikev1-diediediediedie... >> >> Yes, I would say so. >> >> I'd even suggest that maybe it needs a CVE against products that have IKEv1 >> turned on by default. > > No, because it is perfectly possible to implement IKEv1 without this > problem. Libreswan is moving towards that, see: > > https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html Making only the initiator be responsible for retransmissions is possible in the IKEv1 Main Mode. However, it is impossible in Aggressive Mode (and in Quick Mode too, although it is irrelevant here). The problem is that the last message comes from the initiator, and if this message got lost, the initiator never knew about it it unless the responder retransmits the response to the very first message from the initiator. It's an immanent feature of IKEv1 caused by odd number of messages in these exchanges. It can't be solved. And besides the possibility of amplification attack, IKEv1 has so many problems, that the only reason it is still used is maintaining interoperability with older products. Regards, Valery. > Paul From nobody Wed Mar 16 09:49:11 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B624B12DA0C; Wed, 16 Mar 2016 09:49:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316164900.12752.46077.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 09:49:00 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:49:00 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-04.txt Pages : 15 Date : 2016-03-16 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-04 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 Wed Mar 16 09:55:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5277B12D9C1 for ; Wed, 16 Mar 2016 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 b1wJ5d-FP-ZM for ; Wed, 16 Mar 2016 09:55:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 03BFB12D569 for ; Wed, 16 Mar 2016 09:55:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQHfn6WDlz23X; Wed, 16 Mar 2016 17:55:29 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id w3xXcp79HZlO; Wed, 16 Mar 2016 17:55:28 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 17:55:28 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 43E6E603BBA1; Wed, 16 Mar 2016 12:55:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 43E6E603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4247EA3C7; Wed, 16 Mar 2016 12:55:27 -0400 (EDT) Date: Wed, 16 Mar 2016 12:55:27 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <744900CC32EC4D9FA505C2FA2433F31F@chichi> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:55:33 -0000 On Wed, 16 Mar 2016, Valery Smyslov wrote: >> No, because it is perfectly possible to implement IKEv1 without this >> problem. Libreswan is moving towards that, see: >> >> https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html > > Making only the initiator be responsible for retransmissions is possible in > the IKEv1 Main Mode. However, it is impossible in Aggressive Mode > (and in Quick Mode too, although it is irrelevant here). > > The problem is that the last message comes from the initiator, and if this > message > got lost, the initiator never knew about it it unless the responder > retransmits the response > to the very first message from the initiator. It's an immanent feature of > IKEv1 > caused by odd number of messages in these exchanges. It can't be solved. I'm confused? Why does it matter if the initial aggressive mode request is lost or the initial aggresside mode response is lost? to the initiator, both look the same, so it should re-transmit its original packet? > And besides the possibility of amplification attack, IKEv1 has so many > problems, that the only reason it is still used is maintaining > interoperability > with older products. It does have a cryptographically stronger PSK :) Paul From nobody Wed Mar 16 10:03:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063B712D9C1 for ; Wed, 16 Mar 2016 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 dDyd2tGeNkOH for ; Wed, 16 Mar 2016 10:03:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 8E8F512DA00 for ; Wed, 16 Mar 2016 10:03:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQHr50y0Gz24C for ; Wed, 16 Mar 2016 18:03:33 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KhoEvnP2PbH5 for ; Wed, 16 Mar 2016 18:03:32 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 16 Mar 2016 18:03:32 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 498CB603BBA1; Wed, 16 Mar 2016 13:03:31 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 498CB603BBA1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 48150A3C7 for ; Wed, 16 Mar 2016 13:03:31 -0400 (EDT) Date: Wed, 16 Mar 2016 13:03:31 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:03:37 -0000 On Wed, 16 Mar 2016, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-04 This version introduces an RSA key size table and a Digitial Signature OID table. It changed some requirement levels in the existing tables and added some missing entries (eg PRF_HMAC_MD5). It also has extended text for the MODP group justifications. Please read carefully and give the authors feedback. We have read many interim versions between ourselves, so we are likely missing some obvious mistakes now :) Paul From nobody Wed Mar 16 10:30:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1DD12D506 for ; Wed, 16 Mar 2016 10:30:08 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gMj6Y-KFg7_6 for ; Wed, 16 Mar 2016 10:30:06 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA2112D536 for ; Wed, 16 Mar 2016 10:30:06 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id l202so24638745lfl.2 for ; Wed, 16 Mar 2016 10:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=1yDYOZN0PtGiLD3U5w1f4HL1EqlBwjIVIfMnyykwJ+8=; b=FiiPW3tCp2B0QvS4vPB36r4+D922aay/7zjpRC11qsZdAqAhXscwregr4ulKtT0CHm G4QnbgglC2bL6zfpaxAEpus8uxCxVUvMowl2QPa5Xvel74QkERrY3g8OC+4WGFxtURaA 2LdTGdnBaNclRPep9kFsNB8n0rQK8aQ4hGxcsK0OnisdUlnpA5qIBkjdbQgHfCiwFGg0 SaAaOlHlUG6dc6B3HRCRrSFkiI1uXnbM5AX8KfVnEI9gPcn9AMqt5hxSem3fF0TIqdSU gVP87w4dsLH+tsmyt8ZVV0QTKmNIZYCTEdilLA5oTlGsN34SYbzrFiXO4vmX+Uoqdos2 LECQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=1yDYOZN0PtGiLD3U5w1f4HL1EqlBwjIVIfMnyykwJ+8=; b=bGTHnhcmpDdidB0wFgRdnVSISJk08C64ts4nTwvbLFZWqGZkjYkYQaTVafadAatPed 2FX24t/mcv4aTYVRrcZV3Qb92UX61WO17Yda1qKRHZkPwILWi1Hf07Omb/4IdqJcCkDG CUHQLkN/Zv2eTLGWZDiMPfFKpS9rpW0ksgH9LZFQLRCTY8boSRZgT7QJRGklNq+80Gl1 TApenYjAcR/l1G2Dv0BQcGspuERq0D4hu6Q/yYH0tw0LbWlLqRxN+MOGxHxlpxSBYDFd /Ewm8sVatqmln9CwSqJOL0pZpY8XvABb8m6bp1JbVdLKpod2OOwAzV/5sHBWiLgdonPu YBRQ== X-Gm-Message-State: AD7BkJKeKMqCWZjuCXulz9MgErANWPiWgCexLkmpqhkKk63p3AEE4bTS3md/Di+mHK3RrQ== X-Received: by 10.25.159.68 with SMTP id i65mr1964101lfe.94.1458149404444; Wed, 16 Mar 2016 10:30:04 -0700 (PDT) Received: from chichi (ppp83-237-35-107.pppoe.mtu-net.ru. [83.237.35.107]) by smtp.gmail.com with ESMTPSA id p134sm712830lfb.48.2016.03.16.10.30.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 10:30:03 -0700 (PDT) Message-ID: <35D23097794140C0A00798A303BE56A3@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> In-Reply-To: Date: Wed, 16 Mar 2016 20:29:58 +0300 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:30:09 -0000 >> The problem is that the last message comes from the initiator, and if this >> message >> got lost, the initiator never knew about it it unless the responder >> retransmits the response >> to the very first message from the initiator. It's an immanent feature of >> IKEv1 >> caused by odd number of messages in these exchanges. It can't be solved. > > I'm confused? Why does it matter if the initial aggressive mode request > is lost or the initial aggresside mode response is lost? to the > initiator, both look the same, so it should re-transmit its original > packet? Aggressive Mode (and Quick Mode) consist of 3 messages. If the initial message from initiator or (the response to it from responder) get lost, that initiator can detect it (it doesn't receive the response) and retransmit its initial message. But once it receives response it sends the third (the last) message to the responder. At this point the exchange is successfully completed from initiator's point of view (and from its point of view there is no reason to restransmit that last message). However, if that last message get lost, then the exchange remains unfinished from responder's point of view. The only thing the responder can do is to retransmit its response to the initiator's initial message to force it to retransmit its last message. In some cases workarounds are possible. For example, the initiator may always retransmit its last message N times. Another workaround is the following. In most cases Quic Mode immediately follows Aggresive Mode. Since in case the last message from initiator get lost the IKE SA is not created yet from responder's point of view, it most likely won't reply at all or will reply with some error like INVALID_MESSAGE_ID. So, no response or error response on initial Quick Mode message immediately followed the last Aggressive Mode message could be an indication for initiator that it must retransmit not only that initial Quick Mode message, but also the last message of Aggressive Mode. But these are plain hacks. If Aggressive Mode happens alone (e.g. when user pressed CONNECT button), then the only way to deal with the possibility of the last message from initiator to get lost is to make a responder to retransmit its response to the initial message. >> And besides the possibility of amplification attack, IKEv1 has so many >> problems, that the only reason it is still used is maintaining >> interoperability >> with older products. > > It does have a cryptographically stronger PSK :) That's true. However, it is almost impossible to use this feature unless peers have fixed IP. Regards, Valery. From nobody Wed Mar 16 10:42:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F912D9EA for ; Wed, 16 Mar 2016 10:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 Pg4ijZ3CZnwr for ; Wed, 16 Mar 2016 10:42:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3902D12D652 for ; Wed, 16 Mar 2016 10:42:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQJhn0zBRz1yK; Wed, 16 Mar 2016 18:42:17 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sYJG2P60MyOO; Wed, 16 Mar 2016 18:42:16 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 18:42:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 508BA600B74F; Wed, 16 Mar 2016 13:42:15 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 508BA600B74F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4C38DA3C7; Wed, 16 Mar 2016 13:42:15 -0400 (EDT) Date: Wed, 16 Mar 2016 13:42:15 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <35D23097794140C0A00798A303BE56A3@chichi> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> <35D23097794140C0A00798A303BE56A3@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:42:21 -0000 On Wed, 16 Mar 2016, Valery Smyslov wrote: >> I'm confused? Why does it matter if the initial aggressive mode request >> is lost or the initial aggresside mode response is lost? to the >> initiator, both look the same, so it should re-transmit its original >> packet? > > Aggressive Mode (and Quick Mode) consist of 3 messages. > If the initial message from initiator or (the response to it from responder) > get lost, that initiator can detect it (it doesn't receive the response) > and retransmit its initial message. But once it receives > response it sends the third (the last) message to the responder. I did not suggest not retransmitting this. I was ONLY talking about the first response packet of any IKEv1 exchange. Once you receive the 2nd packet on the responder, it has your SPI's so you know the source IP was not spoofed and so you don't need to worry about amplification. > But these are plain hacks. If Aggressive Mode happens alone > (e.g. when user pressed CONNECT button), then the only way to deal > with the possibility of the last message from initiator to get lost is to > make a responder to retransmit its response to the initial message. I still do not see that: AggrOutI1 ---> <---- AggrOutR1 [ rest of exchange ] If AggrOutI1 is dropped: AggrOutI1 ---> X AggrOutI1 ---> <---- AggrOutR1 [ rest of exchange ] If AggrOutR1 is dropped: AggrOutI1 ---> X <---- AggrOutR1 AggrOutI1 ---> <---- AggrOutR1 [ rest of exchange ] Paul From nobody Wed Mar 16 10:50:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2912D748 for ; Wed, 16 Mar 2016 10:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IwVvHDvscwwl for ; Wed, 16 Mar 2016 10:50:22 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7583112D62A for ; Wed, 16 Mar 2016 10:50:22 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id k12so52908309lbb.1 for ; Wed, 16 Mar 2016 10:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=0wvwxDHGKwveXjOJzZuDZ/0bqMOMNW+yTZEp9hK8We8=; b=KTlWBvvn/wtIpBpfa3Z6iQq36hBKZcGanKc0Ue2j/CWqugAGoOnSNdO6mtpWunMBIk qbTZY19LUCATQb/t/uXbopTIWXwPUA0lNQF6J5XaEzzONF3hgdDgRi0OlKwUJ9gQ4AjF Z1GMjL4EP6chOAkJ5PIKVoRblo/C49WROEJ+lXU3VCl5HELlPCePf3ZrlXiUhhH07oZy S/UvDK0Cc69VBMhc9klz3oGf6/IwLqoYrV6mBzeaStl2EVo/W96qydHUXBgudkNZtaP+ luUTm1XjDD6qbSSbTMS19YE8MYUtZpTyRvC/mI4GUnNiOSnRiuD1oCkTAK+zlXZQ1vZp 1Jdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=0wvwxDHGKwveXjOJzZuDZ/0bqMOMNW+yTZEp9hK8We8=; b=grJycnrCxS0OUVFIDvQ2g671PHASI09LiVeDZSBiPIYbixg2b0MSlvUEH9SmweQZwM f1SzetC2Z3UUwI6hjfbIJ+6zVREvtjUawSCrowDl5DIVZI54zkMdccrXcEG3C4lCNaom WtNMvEhlvHuctqfK0E7y91IKNB1s/oGmE3PztRFBbg2++F/jECfPWYELTecTn4YwaIiP 1VyA1CyViJy0kg9j7+Sa/RoN/WqnSpSCet79ecnmO9VLHpc2qx+h8Q/OXL4OLsKvY78N gx1WE4Q7LS8o+Wd5d2li0zFgOh7YPz5pCmaawWJssmr5MgUngivFXCYuiybyWXS8pnPm W3+w== X-Gm-Message-State: AD7BkJL7inEm6Y/QHxO5oZSTQzuJ76yotDSfx2zf1G9mXEcl2kxjSpVLxxtX0aX6FyOeMQ== X-Received: by 10.112.163.201 with SMTP id yk9mr1965801lbb.100.1458150620663; Wed, 16 Mar 2016 10:50:20 -0700 (PDT) Received: from chichi (ppp83-237-43-234.pppoe.mtu-net.ru. [83.237.43.234]) by smtp.gmail.com with ESMTPSA id i8sm709914lbj.30.2016.03.16.10.50.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 10:50:19 -0700 (PDT) Message-ID: <5A253E71FB7F4DE08A02BF2690077B86@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> <35D23097794140C0A00798A303BE56A3@chichi> In-Reply-To: Date: Wed, 16 Mar 2016 20:50:15 +0300 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:50:24 -0000 > I still do not see that: > > > AggrOutI1 ---> > <---- AggrOutR1 > [ rest of exchange ] > > If AggrOutI1 is dropped: > > AggrOutI1 ---> X > AggrOutI1 ---> > <---- AggrOutR1 > [ rest of exchange ] > > If AggrOutR1 is dropped: > > AggrOutI1 ---> > X <---- AggrOutR1 > AggrOutI1 ---> > <---- AggrOutR1 > [ rest of exchange ] "rest of exchange" is most important thing here AggrOutI1 ---> <---- AggrOutR1 AggOutI2 ---> X at this point initiator completed the exchange and has working IKE SA. However, since AggOutI2 is lost, then responder doesn't have IKE SA yet. Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2. The only way responder can force initiator to retransmit AggOutI2 is to retransmit AggrOutR1: AggrOutI1 ---> <---- AggrOutR1 AggOutI2 ---> X <---- AggrOutR1 AggOutI2 ---> From nobody Wed Mar 16 13:29:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCE912D67F for ; Wed, 16 Mar 2016 13:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 ieLqMopz_Fjw for ; Wed, 16 Mar 2016 13:29:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 64E0D12D584 for ; Wed, 16 Mar 2016 13:29:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qQNPL6m93z1yK; Wed, 16 Mar 2016 21:29:10 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BPhsKm4v8N_Y; Wed, 16 Mar 2016 21:29:10 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Mar 2016 21:29:10 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B2A956019B73; Wed, 16 Mar 2016 16:29:07 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B2A956019B73 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AE01D26087; Wed, 16 Mar 2016 16:29:07 -0400 (EDT) Date: Wed, 16 Mar 2016 16:29:07 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <5A253E71FB7F4DE08A02BF2690077B86@chichi> Message-ID: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> <35D23097794140C0A00798A303BE56A3@chichi> <5A253E71FB7F4DE08A02BF2690077B86@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Libreswan Development List Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:29:15 -0000 On Wed, 16 Mar 2016, Valery Smyslov wrote: [ on not sending retransmits in AggrOutR1 state ] > "rest of exchange" is most important thing here > > AggrOutI1 ---> > <---- AggrOutR1 > AggOutI2 ---> X > > at this point initiator completed the exchange and has working IKE SA. > However, since AggOutI2 is lost, then responder doesn't have IKE SA yet. > Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2. > The only way responder can force initiator to retransmit AggOutI2 is > to retransmit AggrOutR1: > > AggrOutI1 ---> > <---- AggrOutR1 > AggOutI2 ---> X > <---- AggrOutR1 > AggOutI2 ---> I see. That is true. Some possible solutions to this: 1) Initiator can always send a DPD probe after 3s to confirm the IKE SA. 2) Initiator waits a few seconds and check if the IPsec SA received incoming traffic as something should have triggered the IKE SA. If not, either tear down IKE SA or do 1) Paul From nobody Wed Mar 16 17:59:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9664812D565 for ; Wed, 16 Mar 2016 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 mTDwXlVr2k45 for ; Wed, 16 Mar 2016 17:59:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8512F12D518 for ; Wed, 16 Mar 2016 17:59:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2H0xCrb011470 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Mar 2016 02:59:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2H0xBtv018167; Thu, 17 Mar 2016 02:59:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22250.351.620694.400927@fireball.acr.fi> Date: Thu, 17 Mar 2016 02:59:11 +0200 From: Tero Kivinen To: "Graham Bartlett \(grbartle\)" In-Reply-To: References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 00:59:27 -0000 Graham Bartlett (grbartle) writes: > There=E2=80=99s many references to IKEv2 in the paper. E.g. There is references to the IKEv2, but the paper is not talking about the IKEv2. It is clear from the packet traces (see version number), and the retransmission behavior seen. In the IKEv2 the responder will NEVER retransmit the response unless initiator retransmits its request (provided the implementation folows what RFC mandates).=20 > "Figure 1: Zmap scan using our IKEv2 payload=E2=80=9D.. >=20 > I=E2=80=99ve managed to track the author down and made contact. I=E2=80= =99ll sync you in > on a mail and hopefully we can verify what was exactly was used. >=20 > All I would ask is - if many IKEv2 implementation are vulnerable to a= n > amplification attack, I feel it would be prudent to add some words to= > remind implementors of the risk. I do not know any IKEv2 implementations that would be vulnerable to this multiple responses attack, and if IKEv2 is implemented as specified in the RFC7296, they are not vulnerable. >From RFC7296: For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request.=20 --=20 kivinen@iki.fi From nobody Wed Mar 16 22:51:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEE12DB6B for ; Wed, 16 Mar 2016 22:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IaLuD1izzZdj for ; Wed, 16 Mar 2016 22:51:27 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F1912DB77 for ; Wed, 16 Mar 2016 22:51:27 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id h198so34583734lfh.0 for ; Wed, 16 Mar 2016 22:51:27 -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-transfer-encoding; bh=C2oflwnfNAXA93S76FFZgXP4z2ZUG4LtB7haWSaqYKA=; b=R3ahpVh8s7BIe8UxELn0vPJaKlOfc812bWja6VM5uLNFjb6FYbh2czFZ5MztiOm2+u r7lWDUaOALkvbJc+t+tXI4q6OvB7TLgUSXb8Crx7MSnC7gPs5B4Zw60/B8dGAuLbP7mw UzUDlCvimuN3Ttz1UGcNArJzp8h0Afiyv7Z5CKAP7yCkFMKf4OMzipSF+qolJ8Rjkya6 NQFP2IQoA642KzrQrBXlAGtDe4PHkjz4Ikr7NIyHOlaReGeLv64+fOkwwglaRnql6bWs h9ZxAqqk9S/ZB5Dp6ZjttBmgcUHPYW4yBEiu1eRBkE+kvOkenG18HCGlYHvfKV1D4L6S UuUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=C2oflwnfNAXA93S76FFZgXP4z2ZUG4LtB7haWSaqYKA=; b=egLPwuD5tFSv62K6MNKw69ORl9Y+F6zZgFN2P/cA3tT8YIn0zuMQW7CqW7OyxHP/P4 qUKHu/qxtCpEB4HuE/ghGGfOXgOW34deJLi3rbWIpa72napb1bMmea6icAYsCTyAmmZg ayBPiIAsCY5xMg/aDpjBgaGbD3QsdrIyq6SJ48gwYQFo14oRdX4ebySM1Hc+wFsF8E38 atknH+8ohUUI/CrFP1zMqv5echoaZUgJSoHWV44Ni6Iw5vOYjPECAVDnf5epFzYppPbE tFpE9a7Er7eKeoTjAs5vZ11ErKg4IlhNUxR0BGBS/yNpYoFZVqKe9MeOxpoo5SX1uBLE WGww== X-Gm-Message-State: AD7BkJLW3EkRpziQV1M0gXe/ziUK3WYud6TQiPKYFQCSxBgumfiwuStB4ieYErWKN7zhng== X-Received: by 10.25.28.80 with SMTP id c77mr2910331lfc.5.1458193885380; Wed, 16 Mar 2016 22:51:25 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k3sm1103981lbp.9.2016.03.16.22.51.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 22:51:24 -0700 (PDT) Message-ID: <86BDF1BB01E3484795EF786627EE606C@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <1913628F357D497DABAB6D43640A02A7@chichi> <66284214-BB02-4987-8E10-9C05B9695A9F@gmail.com> <22248.44588.71321.602201@fireball.acr.fi> <11877.1458134582@obiwan.sandelman.ca> <744900CC32EC4D9FA505C2FA2433F31F@chichi> <35D23097794140C0A00798A303BE56A3@chichi> <5A253E71FB7F4DE08A02BF2690077B86@chichi> Date: Thu, 17 Mar 2016 08:51:25 +0300 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: Cc: ipsec@ietf.org, Libreswan Development List Subject: Re: [IPsec] IKEv1 retransmits - was Re: WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 05:51:34 -0000 >> at this point initiator completed the exchange and has working IKE SA. >> However, since AggOutI2 is lost, then responder doesn't have IKE SA yet. >> Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2. >> The only way responder can force initiator to retransmit AggOutI2 is >> to retransmit AggrOutR1: >> >> AggrOutI1 ---> >> <---- AggrOutR1 >> AggOutI2 ---> X >> <---- AggrOutR1 >> AggOutI2 ---> > > I see. That is true. Some possible solutions to this: > > 1) Initiator can always send a DPD probe after 3s to confirm the IKE SA. Sure. > 2) Initiator waits a few seconds and check if the IPsec SA received > incoming traffic as something should have triggered the IKE SA. > If not, either tear down IKE SA or do 1) No, it'll work differently. To have IPsec SA the initiator must initiate Quick Mode right after Phase I is completed. And the Quick Mode will fail since the responder didn't complete Aggressive Mode exchange. But these workarounds just solve the "black hole" problem, so they allow the initiator to detect, that the responder doesn't have an IKE SA. Sometime it'll become evident for the initiator in any case, even without DPD etc. The problem with IKEv1 is that if the responder never retransmits in Aggressive (and Quick) Mode, then the protocol becomes intolerable to a single packet loss that makes it very unreliable. And it can't be solved. > Paul Regards, Valery. From nobody Thu Mar 17 05:16:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598D812D535 for ; Thu, 17 Mar 2016 05:16: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 autolearn_force=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 a3gzLCVD1MfI for ; Thu, 17 Mar 2016 05:16:15 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E321912D92C for ; Thu, 17 Mar 2016 05:16:14 -0700 (PDT) Received: from [10.71.10.101] (209.31.148.3.ptr.us.xo.net [209.31.148.3]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2HCGCCW074353 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2016 05:16:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 209.31.148.3.ptr.us.xo.net [209.31.148.3] claimed to be [10.71.10.101] From: "Paul Hoffman" To: "ipsec@ietf.org WG" Date: Thu, 17 Mar 2016 08:16:12 -0400 Message-ID: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:16:16 -0000 This version has many significant changes from the previous draft. Please review it soon so we don't have a lot of surprises in WG Last Call. --Paul Hoffman From nobody Fri Mar 18 15:07:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F5912D6DA for ; Fri, 18 Mar 2016 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 M2EZhqxiitTy for ; Fri, 18 Mar 2016 15:07:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC8C12D684 for ; Fri, 18 Mar 2016 15:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108952; q=dns/txt; s=iport; t=1458338853; x=1459548453; h=from:to:subject:date:message-id:mime-version; bh=C8wwdciDKXizH4U2xoNm2x6gnhb15pfhg0jzst+ANsc=; b=cHKINKk2vBrZ3fFui7Q5SIqX+EilSFwSy4vYdiEyNbsRrnZPnmS1NQBU bCv0MzrPo/o+kmBgOBAKNGHHh6CA+xwVXiYzvn821JjuQcapAP7TwyLGS h87aTvkVXD41nJSi0SXBzhumj7Wg7mc2KmCo29JGpKqERbXC5R+YdWYow s=; X-Files: draft-ietf-ipsecme-ddos-protection-05.txt, smime.p7s : 73516, 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArCgBhe+xW/51dJa1VBgODRFMuRAama?= =?us-ascii?q?YdiB4FhAYlygWwDFwqCPIMwAoExORMBAQEBAQEBZCeEQQEBAQICAQEBCwwBDD4?= =?us-ascii?q?JBhECBAEIEQEDAQEWAxgZBgYLFwYKBAESCQUNh3cDEg67ew2EYgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQ0IBIYag0V/gj6BSAYHAwEFAgEBAQMCAgIYEAsLDAcIB4U?= =?us-ascii?q?IBYddAwqGCXmCZYEzhCIBBSsBgx2BZm1tggWCakKBdYFlFjWDf4c9gRuHMYdUA?= =?us-ascii?q?SIBP4F+AgIBBRSBSWqJKAEBHgQDFn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,357,1454976000"; d="txt'?p7s'?scan'208";a="82563693" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2016 22:07:31 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2IM7VZw022000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 22:07:31 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Mar 2016 17:07:30 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Fri, 18 Mar 2016 17:07:30 -0500 From: "Graham Bartlett (grbartle)" To: "Waltermire, David A. (Fed)" , IPsecME WG Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AQHRgWKQEN1mpUdbReie8Bmkunv/FQ== Date: Fri, 18 Mar 2016 22:07:30 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3541183643_855846" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 22:07:38 -0000 --B_3541183643_855846 Content-type: multipart/mixed; boundary="B_3541183643_879632" --B_3541183643_879632 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Updated proposal attached. I=B9ve made some amendments to the proposed text based on Valerys comments. I=B9ve also added text around the correct sending of INFORMATIONAL messages due to a Responder receiving an SA_INIT, this is a known problem today with a number of implementations. (seen by Tero and myself). I have also moved text to section 11. Security Consideration. I=B9ve added some words around the checking of the IDi/IDr. I=B9ve personally seen some issues when misconfigured clients have presented an identical IDi, resulting in INITIAL_CONTACT deleting the =8Cother=B9 clients SA.. I did think about exhaustion of IP addresses when using configuration payload to allocate clients IPs, if a malicious or misconfigured client could exhaust the pool. But I feel the wording in section 8 covers this. Unless others think otherwise? cheers On 16/03/2016 14:21, "IPsec on behalf of Waltermire, David A. (Fed)" wrote: >This is just a friendly reminder that the WGLC on >draft-ietf-ipsecme-ddos-protection-04.txt ends on March 18th, 2016. > >The list discussion has been good on the draft. Thank you to everyone >that commented so far. > >If you have any additional comments, please send them to the list by the >end of the day UTC on Friday. > >Thanks, >Dave > >> -----Original Message----- >> From: Waltermire, David A. (Fed) >> Sent: Tuesday, March 01, 2016 10:34 AM >> To: IPsecME WG >> Subject: WGLC on draft-ietf-ipsecme-ddos-protection-04 >>=20 >> All: >>=20 >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I >>believe the >> draft is shaping up nicely, but needs additional review. To that end, >>this >> message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme- >> ddos-protection-04. >>=20 >> The version to be reviewed is >>https://tools.ietf.org/id/draft-ietf-ipsecme- >> ddos-protection-04.txt. >>=20 >> Please send your comments, questions, and edit proposals to the WG mail >> list until March 18, 2015. If you believe that the document is ready >>to be >> submitted to the IESG for consideration as a Standards Track RFC please >>send >> a short message stating this. >>=20 >> Best Regards, >> Dave > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3541183643_879632 Content-type: text/plain; name="draft-ietf-ipsecme-ddos-protection-05.txt" Content-disposition: attachment; filename="draft-ietf-ipsecme-ddos-protection-05.txt" Content-transfer-encoding: base64 IAoKCgpJUFNlY01FIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBZLiBOaXIKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoZWNrIFBvaW50CkludGVuZGVkIHN0 YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVi4g U215c2xvdgpFeHBpcmVzOiBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVMVklTLVBMVVMKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLkJhcnRsZXR0CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lz Y28gU3lzdGVtcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1hcmNoIDgsIDIwMTYKCgogICAgICBQcm90ZWN0aW5nIEludGVy bmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCB2ZXJzaW9uIDIgKElLRXYyKQogICAgICAgSW1w bGVtZW50YXRpb25zIGZyb20gRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2UgQXR0YWNr cwogICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBzZWNtZS1kZG9zLXByb3RlY3Rpb24t MDUKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMgaW1wbGVtZW50YXRp b24gYW5kIGNvbmZpZ3VyYXRpb24gYmVzdAogICBwcmFjdGljZXMgZm9yIEludGVybmV0IEtl eSBFeGNoYW5nZSBQcm90b2NvbCB2ZXJzaW9uIDIgKElLRXYyKQogICBSZXNwb25kZXJzLCB0 byBhbGxvdyB0aGVtIHRvIHJlc2lzdCBEZW5pYWwgb2YgU2VydmljZSBhbmQgRGlzdHJpYnV0 ZWQKICAgRGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNrcy4gIEFkZGl0aW9uYWxseSwgdGhlIGRv Y3VtZW50IGludHJvZHVjZXMgYQogICBuZXcgbWVjaGFuaXNtIGNhbGxlZCAiQ2xpZW50IFB1 enpsZXMiIHRoYXQgaGVscCBhY2NvbXBsaXNoIHRoaXMgdGFzay4KClN0YXR1cyBvZiBUaGlz IE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0 cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDks IDIwMTYuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTYgSUVURiBU cnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0 aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9u cyB3aXRoIHJlc3BlY3QKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2Vw dGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2gg MjAxNgoKCiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVk IGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIAoKCk5pciAmIFNteXNsb3YgJiBC YXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAg ICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25z IGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4g dGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4g IEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICAyCiAgICAgMS4xLiAgVGhlIFN0YXRlbGVzcyBDb29raWUgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDEuMi4gIENvbnZlbnRpb25z IFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAg Mi4gIFRoZSBWdWxuZXJhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0CiAgIDMuICBQdXp6bGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA0LiAgUmV0ZW50aW9uIFBl cmlvZHMgZm9yIEhhbGYtT3BlbiBTQXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgK ICAgNS4gIFJhdGUgTGltaXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA5CiAgIDYuICBQbGFuIGZvciBEZWZlbmRpbmcgYSBSZXNwb25k ZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMAogICAgIDYuMS4gIFNlc3Np b24gUmVzdW1wdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTIKICAgNy4gIFVzaW5nIFB1enpsZXMgaW4gdGhlIFByb3RvY29sIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgNy4xLiAgUHV6emxlcyBpbiBJS0VfU0FfSU5J VCBFeGNoYW5nZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMgogICAgICAgNy4xLjEu ICBQcmVzZW50aW5nIFB1enpsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTMKICAgICAgIDcuMS4yLiAgU29sdmluZyBQdXp6bGUgYW5kIFJldHVybmluZyB0aGUg U29sdXRpb24gLiAuIC4gLiAuIC4gIDE1CiAgICAgICA3LjEuMy4gIENvbXB1dGluZyBQdXp6 bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNgogICAgICAgNy4x LjQuICBBbmFseXppbmcgUmVwZWF0ZWQgUmVxdWVzdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTYKICAgICAgIDcuMS41LiAgTWFraW5nIERlY2lzaW9uIHdoZXRoZXIgdG8gU2Vy dmUgdGhlIFJlcXVlc3QgIC4gLiAuIC4gIDE4CiAgICAgNy4yLiAgUHV6emxlcyBpbiBJS0Vf QVVUSCBFeGNoYW5nZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICAgICAg Ny4yLjEuICBQcmVzZW50aW5nIFB1enpsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTkKICAgICAgIDcuMi4yLiAgU29sdmluZyBQdXp6bGUgYW5kIFJldHVybmlu ZyB0aGUgU29sdXRpb24gLiAuIC4gLiAuIC4gIDIwCiAgICAgICA3LjIuMy4gIENvbXB1dGlu ZyBQdXp6bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMQogICAg ICAgNy4yLjQuICBSZWNlaXZpbmcgUHV6emxlIFNvbHV0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMjEKICAgOC4gIERvUyBQcm90ZWN0aW9uIGFmdGVyIElLRSBTQSBpcyBj cmVhdGVkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyCiAgIDkuICBQYXlsb2FkIEZvcm1h dHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMwog ICAgIDkuMS4gIFBVWlpMRSBOb3RpZmljYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjMKICAgICA5LjIuICBQdXp6bGUgU29sdXRpb24gUGF5bG9hZCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0CiAgIDEwLiBPcGVyYXRpb25h bCBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAy NAogICAxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjUKICAgMTIuIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMwCiAgIDEzLiBBY2tub3ds ZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzMAogICAxNC4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMzAKICAgICAxNC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMwCiAgICAgMTQuMi4g IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzMQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzEKCiAgICAxLiAgSW50cm9kdWN0aW9uCgogICBE ZW5pYWwgb2YgU2VydmljZSAoRG9TKSBhdHRhY2tzIGhhdmUgYWx3YXlzIGJlZW4gY29uc2lk ZXJlZCBhIHNlcmlvdXMKICAgdGhyZWF0LiAgVGhlc2UgYXR0YWNrcyBhcmUgdXN1YWxseSBk aWZmaWN1bHQgdG8gZGVmZW5kIGFnYWluc3Qgc2luY2UKICAgdGhlIGFtb3VudCBvZiByZXNv dXJjZXMgdGhlIHZpY3RpbSBoYXMgaXMgYWx3YXlzIGJvdW5kZWQgKHJlZ2FyZGxlc3MKICAg b2YgaG93IGhpZ2ggaXQgaXMpIGFuZCBiZWNhdXNlIHNvbWUgcmVzb3VyY2VzIGFyZSByZXF1 aXJlZCBmb3IKICAgZGlzdGluZ3Vpc2hpbmcgYSBsZWdpdGltYXRlIHNlc3Npb24gZnJvbSBh biBhdHRhY2suCgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVt YmVyIDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAx NgoKCiAgIFRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgcHJvdG9jb2wgKElLRSkgZGVzY3Jp YmVkIGluIFtSRkM3Mjk2XQogICBpbmNsdWRlcyBkZWZlbnNlIGFnYWluc3QgRG9TIGF0dGFj a3MuICBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBpcyBhCiAgIGNvb2tpZSBtZWNoYW5pc20gdGhh dCBhbGxvd3MgdGhlIElLRSBSZXNwb25kZXIgdG8gZWZmZWN0aXZlbHkgZGVmZW5kCiAgIGl0 c2VsZiBhZ2FpbnN0IERvUyBhdHRhY2tzIGZyb20gc3Bvb2ZlZCBJUC1hZGRyZXNzZXMuICBI b3dldmVyLCBib3QtCiAgIG5ldHMgaGF2ZSBiZWNvbWUgd2lkZXNwcmVhZCwgYWxsb3dpbmcg YXR0YWNrZXJzIHRvIHBlcmZvcm0KICAgRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2Ug KEREb1MpIGF0dGFja3MsIHdoaWNoIGFyZSBtb3JlCiAgIGRpZmZpY3VsdCB0byBkZWZlbmQg YWdhaW5zdC4gIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgcmVjb21tZW5kYXRpb25zCiAgIHRv IGhlbHAgdGhlIFJlc3BvbmRlciB0aHdhcnQgKEQpRG9TIGF0dGFja3MuICBJdCBhbHNvIGlu dHJvZHVjZXMgYQogICBuZXcgbWVjaGFuaXNtIC0tICJwdXp6bGVzIiAtLSB0aGF0IGNhbiBo ZWxwIGFjY29tcGxpc2ggdGhpcyB0YXNrLgoKICAgVGhlIElLRV9TQV9JTklUIEV4Y2hhbmdl IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEuMiBvZiBbUkZDNzI5Nl0KICAgaW52b2x2ZXMgdGhl IEluaXRpYXRvciBzZW5kaW5nIGEgc2luZ2xlIG1lc3NhZ2UuICBUaGUgUmVzcG9uZGVyCiAg IHJlcGxpZXMgd2l0aCBhIHNpbmdsZSBtZXNzYWdlIGFuZCBhbHNvIGFsbG9jYXRlcyBtZW1v cnkgZm9yIGEKICAgc3RydWN0dXJlIGNhbGxlZCBhIGhhbGYtb3BlbiBJS0UgU2VjdXJpdHkg QXNzb2NpYXRpb24gKFNBKS4gIFRoaXMKICAgaGFsZi1vcGVuIFNBIGlzIGxhdGVyIGF1dGhl bnRpY2F0ZWQgaW4gdGhlIElLRV9BVVRIIEV4Y2hhbmdlLiAgSWYKICAgdGhhdCBJS0VfQVVU SCByZXF1ZXN0IG5ldmVyIGNvbWVzLCB0aGUgaGFsZi1vcGVuIFNBIGlzIGtlcHQgZm9yIGFu CiAgIHVuc3BlY2lmaWVkIGFtb3VudCBvZiB0aW1lLiAgRGVwZW5kaW5nIG9uIHRoZSBhbGdv cml0aG1zIHVzZWQgYW5kCiAgIGltcGxlbWVudGF0aW9uLCBzdWNoIGEgaGFsZi1vcGVuIFNB IHdpbGwgdXNlIGZyb20gYXJvdW5kIDEwMCBieXRlcyB0bwogICBzZXZlcmFsIHRob3VzYW5k cyBieXRlcyBvZiBtZW1vcnkuCgogICBUaGlzIGNyZWF0ZXMgYW4gZWFzeSBhdHRhY2sgdmVj dG9yIGFnYWluc3QgYW4gSUtFIFJlc3BvbmRlci4KICAgR2VuZXJhdGluZyB0aGUgSUtFX1NB X0lOSVQgcmVxdWVzdCBpcyBjaGVhcCwgYW5kIHNlbmRpbmcgbXVsdGlwbGUKICAgc3VjaCBy ZXF1ZXN0cyBjYW4gZWl0aGVyIGNhdXNlIHRoZSBSZXNwb25kZXIgdG8gYWxsb2NhdGUgdG9v IG11Y2gKICAgcmVzb3VyY2VzIGFuZCBmYWlsLCBvciBlbHNlIGlmIHJlc291cmNlIGFsbG9j YXRpb24gaXMgc29tZWhvdwogICB0aHJvdHRsZWQsIGxlZ2l0aW1hdGUgSW5pdGlhdG9ycyB3 b3VsZCBhbHNvIGJlIHByZXZlbnRlZCBmcm9tIHNldHRpbmcKICAgdXAgSUtFIFNBcy4KCiAg IEFuIG9idmlvdXMgZGVmZW5zZSwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNSwg aXMgbGltaXRpbmcgdGhlCiAgIG51bWJlciBvZiBoYWxmLW9wZW4gU0FzIG9wZW5lZCBieSBh IHNpbmdsZSBwZWVyLiAgSG93ZXZlciwgc2luY2UgYWxsCiAgIHRoYXQgaXMgcmVxdWlyZWQg aXMgYSBzaW5nbGUgcGFja2V0LCBhbiBhdHRhY2tlciBjYW4gdXNlIG11bHRpcGxlCiAgIHNw b29mZWQgc291cmNlIElQIGFkZHJlc3Nlcy4KCiAgICAgIDEuMS4gIFRoZSBTdGF0ZWxlc3Mg Q29va2llCgogICBTZWN0aW9uIDIuNiBvZiBbUkZDNzI5Nl0gb2ZmZXJzIGEgbWVjaGFuaXNt IHRvIG1pdGlnYXRlIHRoaXMgRG9TCiAgIGF0dGFjazogdGhlIHN0YXRlbGVzcyBjb29raWUu ICBXaGVuIHRoZSBzZXJ2ZXIgaXMgdW5kZXIgbG9hZCwgdGhlCiAgIFJlc3BvbmRlciByZXNw b25kcyB0byB0aGUgSUtFX1NBX0lOSVQgcmVxdWVzdCB3aXRoIGEgY2FsY3VsYXRlZAogICAi c3RhdGVsZXNzIGNvb2tpZSIgLSBhIHZhbHVlIHRoYXQgY2FuIGJlIHJlLWNhbGN1bGF0ZWQg YmFzZWQgb24KICAgdmFsdWVzIGluIHRoZSBJS0VfU0FfSU5JVCByZXF1ZXN0IHdpdGhvdXQg c3RvcmluZyBSZXNwb25kZXItc2lkZQogICBzdGF0ZS4gIFRoZSBJbml0aWF0b3IgaXMgZXhw ZWN0ZWQgdG8gcmVwZWF0IHRoZSBJS0VfU0FfSU5JVCByZXF1ZXN0LAogICB0aGlzIHRpbWUg aW5jbHVkaW5nIHRoZSBzdGF0ZWxlc3MgY29va2llLgoKICAgQXR0YWNrZXJzIHRoYXQgaGF2 ZSBtdWx0aXBsZSBzb3VyY2UgSVAgYWRkcmVzc2VzIHdpdGggcmV0dXJuCiAgIHJvdXRhYmls aXR5LCBzdWNoIGFzIGluIHRoZSBjYXNlIG9mIGJvdC1uZXRzLCBjYW4gZmlsbCB1cCBhIGhh bGYtb3BlbgogICBTQSB0YWJsZSBhbnl3YXkuICBUaGUgY29va2llIG1lY2hhbmlzbSBsaW1p dHMgdGhlIGFtb3VudCBvZiBhbGxvY2F0ZWQKICAgc3RhdGUgdG8gdGhlIHNpemUgb2YgdGhl IGJvdC1uZXQsIG11bHRpcGxpZWQgYnkgdGhlIG51bWJlciBvZiBoYWxmLQogICBvcGVuIFNB cyBhbGxvd2VkIHBlciBwZWVyIGFkZHJlc3MsIG11bHRpcGxpZWQgYnkgdGhlIGFtb3VudCBv ZiBzdGF0ZQoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVy IDksIDIwMTYgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAxNgoK CiAgIGFsbG9jYXRlZCBmb3IgZWFjaCBoYWxmLW9wZW4gU0EuICBXaXRoIHR5cGljYWwgdmFs dWVzIHRoaXMgY2FuIGVhc2lseQogICByZWFjaCBodW5kcmVkcyBvZiBtZWdhYnl0ZXMuCgog ICBUaGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMgYWRkcyBhIHByb29mIG9m IHdvcmsgZm9yIHRoZQogICBJbml0aWF0b3IgYnkgY2FsY3VsYXRpbmcgYSBwcmUtaW1hZ2Ug Zm9yIGEgcGFydGlhbCBoYXNoIHZhbHVlLiAgVGhpcwogICBzZXRzIGFuIHVwcGVyIGJvdW5k LCBkZXRlcm1pbmVkIGJ5IHRoZSBhdHRhY2tlcidzIENQVSwgdG8gdGhlIG51bWJlcgogICBv ZiBuZWdvdGlhdGlvbnMgaXQgY2FuIGluaXRpYXRlIGluIGEgdW5pdCBvZiB0aW1lLgoKICAg ICAgMS4yLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERvY3VtZW50CgogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVki LCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAgIDIuICBUaGUgVnVsbmVyYWJp bGl0eQoKICAgSWYgd2UgYnJlYWsgZG93biB3aGF0IGEgUmVzcG9uZGVyIGhhcyB0byBkbyBk dXJpbmcgYW4gaW5pdGlhbAogICBleGNoYW5nZSwgdGhlcmUgYXJlIHRocmVlIHN0YWdlczoK CiAgICAgICAxLiAgV2hlbiB0aGUgSUtFX1NBX0lOSVQgcmVxdWVzdCBhcnJpdmVzLCB0aGUg UmVzcG9uZGVyOgoKICAgICAgICAgICogIEdlbmVyYXRlcyBvciByZS11c2VzIGEgRGlmZmll LUhlbGxtYW4gKEQtSCkgcHJpdmF0ZSBwYXJ0LgoKICAgICAgICAgICogIEdlbmVyYXRlcyBh IFJlc3BvbmRlciBTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXggKFNQSSkuCgogICAgICAgICAg KiAgU3RvcmVzIHRoZSBwcml2YXRlIHBhcnQgYW5kIHBlZXIgcHVibGljIHBhcnQgaW4gYSBo YWxmLW9wZW4KICAgICAgICAgIFNBIGRhdGFiYXNlLgoKICAgICAgIDIuICBXaGVuIHRoZSBJ S0VfQVVUSCByZXF1ZXN0IGFycml2ZXMsIHRoZSBSZXNwb25kZXI6CgogICAgICAgICAgKiAg RGVyaXZlcyB0aGUga2V5cyBmcm9tIHRoZSBoYWxmLW9wZW4gU0EuCgogICAgICAgICAgKiAg RGVjcnlwdHMgdGhlIHJlcXVlc3QuCgogICAgICAgMy4gIElmIHRoZSBJS0VfQVVUSCByZXF1 ZXN0IGRlY3J5cHRzIHByb3Blcmx5OgoKICAgICAgICAgICogIFZhbGlkYXRlcyB0aGUgY2Vy dGlmaWNhdGUgY2hhaW4gKGlmIHByZXNlbnQpIGluIHRoZQogICAgICAgICAgSUtFX0FVVEgg cmVxdWVzdC4KCiAgIFllcywgdGhlcmUncyBhIHN0YWdlIDQgd2hlcmUgdGhlIFJlc3BvbmRl ciBhY3R1YWxseSBjcmVhdGVzIENoaWxkCiAgIFNBcywgYnV0IHdoZW4gdGFsa2luZyBhYm91 dCAoRClEb1MsIHdlIG5ldmVyIGdldCB0byB0aGlzIHN0YWdlLgoKICAgU3RhZ2UgIzEgaXMg cHJldHR5IGxpZ2h0IG9uIENQVSBwb3dlciwgYnV0IHJlcXVpcmVzIHNvbWUgc3RvcmFnZSwg YW5kCiAgIGl0J3MgdmVyeSBsaWdodCBmb3IgdGhlIEluaXRpYXRvciBhcyB3ZWxsLiAgU3Rh Z2UgIzIgaW5jbHVkZXMKICAgcHJpdmF0ZS1rZXkgb3BlcmF0aW9ucywgc28gaXQncyBtdWNo IGhlYXZpZXIgQ1BVLXdpc2UuICBTdGFnZSAjMwogICBpbmNsdWRlcyBwdWJsaWMga2V5IG9w ZXJhdGlvbnMsIHR5cGljYWxseSBtb3JlIHRoYW4gb25lLgoKCiAKCgpOaXIgJiBTbXlzbG92 ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtF djIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBUbyBhdHRhY2sgc3VjaCBhIFJlc3Bv bmRlciwgYW4gYXR0YWNrZXIgY2FuIGF0dGVtcHQgdG8gZWl0aGVyIGV4aGF1c3QKICAgbWVt b3J5IG9yIHRvIGV4aGF1c3QgQ1BVLiAgV2l0aG91dCBhbnkgcHJvdGVjdGlvbiwgdGhlIG1v c3QgZWZmaWNpZW50CiAgIGF0dGFjayBpcyB0byBzZW5kIG11bHRpcGxlIElLRV9TQV9JTklU IHJlcXVlc3RzIGFuZCBleGhhdXN0IG1lbW9yeS4KICAgVGhpcyBzaG91bGQgYmUgZWFzeSBi ZWNhdXNlIHRob3NlIHJlcXVlc3RzIGFyZSBjaGVhcC4KCiAgIFRoZXJlIGFyZSBvYnZpb3Vz IHdheXMgZm9yIHRoZSBSZXNwb25kZXIgdG8gcHJvdGVjdCBpdHNlbGYgZXZlbgogICB3aXRo b3V0IGNoYW5nZXMgdG8gdGhlIHByb3RvY29sLiAgSXQgY2FuIHJlZHVjZSB0aGUgdGltZSB0 aGF0IGFuCiAgIGVudHJ5IHJlbWFpbnMgaW4gdGhlIGhhbGYtb3BlbiBTQSBkYXRhYmFzZSwg YW5kIGl0IGNhbiBsaW1pdCB0aGUKICAgYW1vdW50IG9mIGNvbmN1cnJlbnQgaGFsZi1vcGVu IFNBcyBmcm9tIGEgcGFydGljdWxhciBhZGRyZXNzIG9yCiAgIHByZWZpeC4gIFRoZSBhdHRh Y2tlciBjYW4gb3ZlcmNvbWUgdGhpcyBieSB1c2luZyBzcG9vZmVkIHNvdXJjZQogICBhZGRy ZXNzZXMuCgogICBUaGUgc3RhdGVsZXNzIGNvb2tpZSBtZWNoYW5pc20gZnJvbSBTZWN0aW9u IDIuNiBvZiBbUkZDNzI5Nl0gcHJldmVudHMKICAgYW4gYXR0YWNrIHdpdGggc3Bvb2ZlZCBz b3VyY2UgYWRkcmVzc2VzLiAgVGhpcyBkb2Vzbid0IGNvbXBsZXRlbHkKICAgc29sdmUgdGhl IGlzc3VlLCBidXQgaXQgbWFrZXMgdGhlIGxpbWl0aW5nIG9mIGhhbGYtb3BlbiBTQXMgYnkK ICAgYWRkcmVzcyBvciBwcmVmaXggd29yay4gIFB1enpsZXMgZG8gdGhlIHNhbWUgdGhpbmcg b25seSBtb3JlIG9mIGl0LgogICBUaGV5IG1ha2UgaXQgaGFyZGVyIGZvciBhbiBhdHRhY2tl ciB0byByZWFjaCB0aGUgZ29hbCBvZiBnZXR0aW5nIGEKICAgaGFsZi1vcGVuIFNBLiAgVGhl eSBkb24ndCBoYXZlIHRvIGJlIHNvIGhhcmQgdGhhdCBhbiBhdHRhY2tlciBjYW4ndAogICBh ZmZvcmQgdG8gc29sdmUgYSBzaW5nbGUgcHV6emxlOyBpdCdzIGVub3VnaCB0aGF0IHRoZXkg aW5jcmVhc2UgdGhlCiAgIGNvc3Qgb2YgYSBoYWxmLW9wZW4gU0FzIGZvciB0aGUgYXR0YWNr ZXIgc28gdGhhdCBpdCBjYW4gY3JlYXRlIG9ubHkgYQogICBmZXcuCgogICBSZWR1Y2luZyB0 aGUgYW1vdW50IG9mIHRpbWUgYW4gYWJhbmRvbmVkIGhhbGYtb3BlbiBTQSBpcyBrZXB0IGF0 dGFja3MKICAgdGhlIGlzc3VlIGZyb20gdGhlIG90aGVyIHNpZGUuICBJdCByZWR1Y2VzIHRo ZSB2YWx1ZSB0aGUgYXR0YWNrZXIKICAgZ2V0cyBmcm9tIG1hbmFnaW5nIHRvIGNyZWF0ZSBh IGhhbGYtb3BlbiBTQS4gIEZvciBleGFtcGxlLCBpZiBhIGhhbGYtCiAgIG9wZW4gU0EgaXMg a2VwdCBmb3IgMSBtaW51dGUgYW5kIHRoZSBjYXBhY2l0eSBpcyA2MCwwMDAgaGFsZi1vcGVu CiAgIFNBcywgYW4gYXR0YWNrZXIgd291bGQgbmVlZCB0byBjcmVhdGUgMSwwMDAgaGFsZi1v cGVuIFNBcyBwZXIgc2Vjb25kLgogICBSZWR1Y2UgdGhlIHJldGVudGlvbiB0aW1lIHRvIDMg c2Vjb25kcywgYW5kIHRoZSBhdHRhY2tlciBuZWVkcyB0bwogICBjcmVhdGUgMjAsMDAwIGhh bGYtb3BlbiBTQXMgcGVyIHNlY29uZC4gIEJ5IGludHJvZHVjaW5nIGEgcHV6emxlLAogICBl YWNoIGhhbGYtb3BlbiBTQSBiZWNvbWVzIG1vcmUgZXhwZW5zaXZlIGZvciBhbiBhdHRhY2tl ciwgbWFraW5nIGl0CiAgIG1vcmUgbGlrZWx5IHRvIHRod2FydCBhbiBleGhhdXN0aW9uIGF0 dGFjayBhZ2FpbnN0IFJlc3BvbmRlciBtZW1vcnkuCgogICBBdCB0aGlzIHBvaW50LCBmaWxs aW5nIHVwIHRoZSBoYWxmLW9wZW4gU0EgZGF0YWJhc2UgaXMgbm8gbG9uZ2VyIHRoZQogICBt b3N0IGVmZmljaWVudCBEb1MgYXR0YWNrLiAgVGhlIGF0dGFja2VyIGhhcyB0d28gd2F5cyB0 byBkbyBiZXR0ZXI6CgogICAgICAgMS4gIEdvIGJhY2sgdG8gc3Bvb2ZlZCBhZGRyZXNzZXMg YW5kIHRyeSB0byBvdmVyd2hlbG0gdGhlIENQVQogICAgICAgdGhhdCBkZWFscyB3aXRoIGdl bmVyYXRpbmcgY29va2llcywgb3IKCiAgICAgICAyLiAgVGFrZSB0aGUgYXR0YWNrIHRvIHRo ZSBuZXh0IGxldmVsIGJ5IGFsc28gc2VuZGluZyBhbiBJS0VfQVVUSAogICAgICAgcmVxdWVz dC4KCiAgIEl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0IHRoaW5nIGNhbm5vdCBiZSBkZWFsdCB3 aXRoIGF0IHRoZSBJS0UgbGV2ZWwuCiAgIEl0J3MgcHJvYmFibHkgYmV0dGVyIGxlZnQgdG8g SW50cnVzaW9uIFByZXZlbnRpb24gU3lzdGVtIChJUFMpCiAgIHRlY2hub2xvZ3kuCgogICBP biB0aGUgb3RoZXIgaGFuZCwgc2VuZGluZyBhbiBJS0VfQVVUSCByZXF1ZXN0IGlzIHN1cnBy aXNpbmdseSBjaGVhcC4KICAgSXQgcmVxdWlyZXMgYSBwcm9wZXIgSUtFIGhlYWRlciB3aXRo IHRoZSBjb3JyZWN0IElLRSBTUElzLCBhbmQgaXQKICAgcmVxdWlyZXMgYSBzaW5nbGUgRW5j cnlwdGVkIHBheWxvYWQuICBUaGUgY29udGVudCBvZiB0aGUgcGF5bG9hZAogCgoKTmlyICYg U215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAg ICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24g Zm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgbWlnaHQgYXMgd2VsbCBi ZSBqdW5rLiAgVGhlIFJlc3BvbmRlciBoYXMgdG8gcGVyZm9ybSB0aGUgcmVsYXRpdmVseQog ICBleHBlbnNpdmUga2V5IGRlcml2YXRpb24sIG9ubHkgdG8gZmluZCB0aGF0IHRoZSBNQUMg b24gdGhlIEVuY3J5cHRlZAogICBwYXlsb2FkIG9uIHRoZSBJS0VfQVVUSCByZXF1ZXN0IGRv ZXMgbm90IGNoZWNrLiAgRGVwZW5kaW5nIG9uIHRoZQogICBSZXNwb25kZXIgaW1wbGVtZW50 YXRpb24sIHRoaXMgY2FuIGJlIHJlcGVhdGVkIHdpdGggdGhlIHNhbWUgaGFsZi0KICAgb3Bl biBTQSAoaWYgdGhlIFJlc3BvbmRlciBkb2VzIG5vdCBkZWxldGUgdGhlIGhhbGYtb3BlbiBT QSBmb2xsb3dpbmcKICAgYW4gdW5zdWNjZXNzZnVsIGRlY3J5cHRpb24gLSBzZWUgZGlzY3Vz c2lvbiBpbiBTZWN0aW9uIDQpLgoKICAgSGVyZSB0b28sIHRoZSBudW1iZXIgb2YgaGFsZi1v cGVuIFNBcyB0aGF0IHRoZSBhdHRhY2tlciBjYW4gYWNoaWV2ZQogICBpcyBjcnVjaWFsLCBi ZWNhdXNlIGVhY2ggb25lIGFsbG93cyB0aGUgYXR0YWNrZXIgdG8gd2FzdGUgc29tZSBDUFUK ICAgdGltZS4gIFNvIG1ha2luZyBpdCBoYXJkIHRvIG1ha2UgbWFueSBoYWxmLW9wZW4gU0Fz IGlzIGltcG9ydGFudC4KCiAgIEEgc3RyYXRlZ3kgYWdhaW5zdCBERG9TIGhhcyB0byByZWx5 IG9uIGF0IGxlYXN0IDQgY29tcG9uZW50czoKCiAgICAgICAxLiAgSGFyZGVuaW5nIHRoZSBo YWxmLW9wZW4gU0EgZGF0YWJhc2UgYnkgcmVkdWNpbmcgcmV0ZW50aW9uCiAgICAgICB0aW1l LgoKICAgICAgIDIuICBIYXJkZW5pbmcgdGhlIGhhbGYtb3BlbiBTQSBkYXRhYmFzZSBieSBy YXRlLWxpbWl0aW5nIHNpbmdsZQogICAgICAgSVBzLyBwcmVmaXhlcy4KCiAgICAgICAzLiAg R3VpZGFuY2Ugb24gd2hhdCB0byBkbyB3aGVuIGFuIElLRV9BVVRIIHJlcXVlc3QgZmFpbHMg dG8KICAgICAgIGRlY3J5cHQuCgogICAgICAgNC4gIEluY3JlYXNpbmcgY29zdCBvZiBoYWxm LW9wZW4gU0EgdXAgdG8gd2hhdCBpcyB0b2xlcmFibGUgZm9yCiAgICAgICBsZWdpdGltYXRl IGNsaWVudHMuCgogICBQdXp6bGVzIGhhdmUgdGhlaXIgcGxhY2UgYXMgcGFydCBvZiAjNC4K CiAgICAzLiAgUHV6emxlcwoKICAgVGhlIHB1enpsZSBpbnRyb2R1Y2VkIGhlcmUgZXh0ZW5k cyB0aGUgY29va2llIG1lY2hhbmlzbSBmcm9tCiAgIFtSRkM3Mjk2XS4gIEl0IGlzIGxvb3Nl bHkgYmFzZWQgb24gdGhlIHByb29mLW9mLXdvcmsgdGVjaG5pcXVlIHVzZWQKICAgaW4gQml0 Y29pbnMgW2JpdGNvaW5zXS4KCiAgIEEgcHV6emxlIGlzIHNlbnQgdG8gdGhlIEluaXRpYXRv ciBpbiB0d28gY2FzZXM6CgogICAgICBvICBUaGUgUmVzcG9uZGVyIGlzIHNvIG92ZXJsb2Fk ZWQgdGhhdCBubyBoYWxmLW9wZW4gU0FzIG1heSBiZQogICAgICBjcmVhdGVkIHdpdGhvdXQg c29sdmluZyBhIHB1enpsZSwgb3IKCiAgICAgIG8gIFRoZSBSZXNwb25kZXIgaXMgbm90IHRv byBsb2FkZWQsIGJ1dCB0aGUgcmF0ZS1saW1pdGluZyBtZXRob2QKICAgICAgZGVzY3JpYmVk IGluIFNlY3Rpb24gNSBwcmV2ZW50cyBoYWxmLW9wZW4gU0FzIGZyb20gYmVpbmcgY3JlYXRl ZAogICAgICB3aXRoIHRoaXMgcGFydGljdWxhciBwZWVyIGFkZHJlc3Mgb3IgcHJlZml4IHdp dGhvdXQgZmlyc3Qgc29sdmluZwogICAgICBhIHB1enpsZS4KCiAgIFdoZW4gdGhlIFJlc3Bv bmRlciBkZWNpZGVzIHRvIHNlbmQgdGhlIGNoYWxsZW5nZSBub3RpZmljYXRpb24gaW4KICAg cmVzcG9uc2UgdG8gYSBJS0VfU0FfSU5JVCByZXF1ZXN0LCB0aGUgbm90aWZpY2F0aW9uIGlu Y2x1ZGVzIHRocmVlCiAgIGZpZWxkczoKCiAgICAgICAxLiAgQ29va2llIC0gdGhpcyBpcyBj YWxjdWxhdGVkIHRoZSBzYW1lIGFzIGluIFtSRkM3Mjk2XSwgaS5lLgogCgoKTmlyICYgU215 c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAg IFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9y IElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgICAgIHRoZSBwcm9jZXNzIG9m IGdlbmVyYXRpbmcgdGhlIGNvb2tpZSBpcyBub3Qgc3BlY2lmaWVkLgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYg QmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2Ug OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIg ICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICAyLiAgQWxnb3JpdGhtLCB0aGlzIGlzIHRo ZSBpZGVudGlmaWVyIG9mIGEgUHNldWRvLVJhbmRvbSBGdW5jdGlvbgogICAgICAgKFBSRikg YWxnb3JpdGhtLCBvbmUgb2YgdGhvc2UgcHJvcG9zZWQgYnkgdGhlIEluaXRpYXRvciBpbiB0 aGUgU0EKICAgICAgIHBheWxvYWQuCgogICAgICAgMy4gIFplcm8gQml0IENvdW50IChaQkMp LiAgVGhpcyBpcyBhIG51bWJlciBiZXR3ZWVuIDggYW5kIDI1NSAob3IKICAgICAgIGEgc3Bl Y2lhbCB2YWx1ZSAtIDAsIHNlZSBTZWN0aW9uIDcuMS4xLjEpIHRoYXQgcmVwcmVzZW50cyB0 aGUKICAgICAgIGxlbmd0aCBvZiB0aGUgemVyby1iaXQgcnVuIGF0IHRoZSBlbmQgb2YgdGhl IG91dHB1dCBvZiB0aGUgUFJGCiAgICAgICBmdW5jdGlvbiBjYWxjdWxhdGVkIG92ZXIgdGhl IGNvb2tpZSB0aGF0IHRoZSBJbml0aWF0b3IgaXMgdG8KICAgICAgIHNlbmQuICBUaGUgdmFs dWVzIDEtOCBhcmUgZXhwbGljaXRseSBleGNsdWRlZCwgYmVjYXVzZSB0aGV5CiAgICAgICBj cmVhdGUgYSBwdXp6bGUgdGhhdCBpcyB0b28gZWFzeSB0byBzb2x2ZSBmb3IgaXQgdG8gbWFr ZSBhbnkKICAgICAgIGRpZmZlcmVuY2UgaW4gbWl0aWdhdGluZyBERG9TIGF0dGFja3MuICBT aW5jZSB0aGUgbWVjaGFuaXNtIGlzCiAgICAgICBzdXBwb3NlZCB0byBiZSBzdGF0ZWxlc3Mg Zm9yIHRoZSBSZXNwb25kZXIsIGVpdGhlciB0aGUgc2FtZSBaQkMKICAgICAgIGlzIHVzZWQg Zm9yIGFsbCBJbml0aWF0b3JzLCBvciB0aGUgWkJDIGlzIHNvbWVob3cgZW5jb2RlZCBpbiB0 aGUKICAgICAgIGNvb2tpZS4gIElmIGl0IGlzIGdsb2JhbCB0aGVuIGl0IG1lYW5zIHRoYXQg dGhpcyB2YWx1ZSBpcyB0aGUKICAgICAgIHNhbWUgZm9yIGFsbCB0aGUgSW5pdGlhdG9ycyB3 aG8gYXJlIHJlY2VpdmluZyBwdXp6bGVzIGF0IGFueQogICAgICAgZ2l2ZW4gcG9pbnQgb2Yg dGltZS4gIFRoZSBSZXNwb25kZXIsIGhvd2V2ZXIsIG1heSBjaGFuZ2UgdGhpcwogICAgICAg dmFsdWUgb3ZlciB0aW1lIGRlcGVuZGluZyBvbiBpdHMgbG9hZC4KCiAgIFVwb24gcmVjZWl2 aW5nIHRoaXMgY2hhbGxlbmdlLCB0aGUgSW5pdGlhdG9yIGF0dGVtcHRzIHRvIGNhbGN1bGF0 ZQogICB0aGUgUFJGIHVzaW5nIGRpZmZlcmVudCBrZXlzLiAgV2hlbiBlbm91Z2gga2V5cyBh cmUgZm91bmQgc3VjaCB0aGF0CiAgIHRoZSByZXN1bHRpbmcgUFJGIG91dHB1dCBjYWxjdWxh dGVkIHVzaW5nIGVhY2ggb2YgdGhlbSBoYXMgYQogICBzdWZmaWNpZW50IG51bWJlciBvZiB0 cmFpbGluZyB6ZXJvIGJpdHMsIHRoYXQgcmVzdWx0IGlzIHNlbnQgdG8gdGhlCiAgIFJlc3Bv bmRlci4KCiAgIFRoZSByZWFzb24gZm9yIHVzaW5nIHNldmVyYWwga2V5cyBpbiB0aGUgcmVz dWx0cyByYXRoZXIgdGhhbiBqdXN0IG9uZQogICBrZXkgaXMgdG8gcmVkdWNlIHRoZSB2YXJp YW5jZSBpbiB0aGUgdGltZSBpdCB0YWtlcyB0aGUgaW5pdGlhdG9yIHRvCiAgIHNvbHZlIHRo ZSBwdXp6bGUuICBXZSBoYXZlIGNob3NlbiB0aGUgbnVtYmVyIG9mIGtleXMgdG8gYmUgZm91 ciAoNCkKICAgYXMgYSBjb21wcm9taXNlIGJldHdlZW4gdGhlIGNvbmZsaWN0aW5nIGdvYWxz IG9mIHJlZHVjaW5nIHZhcmlhbmNlCiAgIGFuZCByZWR1Y2luZyB0aGUgd29yayB0aGUgUmVz cG9uZGVyIG5lZWRzIHRvIHBlcmZvcm0gdG8gdmVyaWZ5IHRoZQogICBwdXp6bGUgc29sdXRp b24uCgogICBXaGVuIHJlY2VpdmluZyBhIHJlcXVlc3Qgd2l0aCBhIHNvbHZlZCBwdXp6bGUs IHRoZSBSZXNwb25kZXIgdmVyaWZpZXMKICAgdHdvIHRoaW5nczoKCiAgICAgIG8gIFRoYXQg dGhlIGNvb2tpZSBwYXJ0IGlzIGluZGVlZCB2YWxpZC4KCiAgICAgIG8gIFRoYXQgdGhlIFBS RnMgb2YgdGhlIHRyYW5zbWl0dGVkIGNvb2tpZSBjYWxjdWxhdGVkIHdpdGggdGhlCiAgICAg IHRyYW5zbWl0dGVkIGtleXMgaGFzIGEgc3VmZmljaWVudCBudW1iZXIgb2YgdHJhaWxpbmcg emVybyBiaXRzLgoKICAgRXhhbXBsZSAxOiBTdXBwb3NlIHRoZSBjYWxjdWxhdGVkIGNvb2tp ZSBpcwogICA3MzlhZTc0OTJkOGE4MTBjZjVlOGRjMGY5NjI2YzlkZGE3NzNjNWEzICgyMCBv Y3RldHMpLCB0aGUgYWxnb3JpdGhtCiAgIGlzIFBSRi1ITUFDLVNIQTI1NiwgYW5kIHRoZSBy ZXF1aXJlZCBudW1iZXIgb2YgemVybyBiaXRzIGlzIDE4LiBBZnRlcgogICBzdWNjZXNzaXZl bHkgdHJ5aW5nIGEgYnVuY2ggb2Yga2V5cywgdGhlIEluaXRpYXRvciBmaW5kcyB0aGUKICAg Zm9sbG93aW5nIGZvdXIgMy1vY3RldCBrZXlzIHRoYXQgd29yazoKCgoKCiAKCgpOaXIgJiBT bXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAg ICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBm b3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICAgICAgICArLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAg ICB8ICBLZXkgICB8IExhc3QgMzIgSGV4IFBSRiBEaWdpdHMgICAgICAgICAgIHwgIyAwLWJp dHMgfAogICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tKwogICAgICAgICB8IDA2MTg0MCB8IGU0Zjk1N2I4NTlkN2ZiMTM0 M2I3Yjk0YTgxNmMwMDAwIHwgICAgMTggICAgfAogICAgICAgICB8IDA3MzMyNCB8IDBkNDIz M2Q2Mjc4Yzk2ZTMzNjkyMjdhMDc1ODAwMDAwIHwgICAgMjMgICAgfAogICAgICAgICB8IDBj OGEyYSB8IDk1MmEzNWQzOWQ1YmEwNjcwOWRhNDNhZjQwNzAwMDAwIHwgICAgMjAgICAgfAog ICAgICAgICB8IDBkOTRjOCB8IDVhMDQ1MmIyMTU3MWU0MDFhM2QwMDgwMzY3OWMwMDAwIHwg ICAgMTggICAgfAogICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgVGFibGUgMTogVGhyZWUgc29sdXRpb25zIGZvciAxOC1iaXQgcHV6emxlCgog ICBFeGFtcGxlIDI6IFNhbWUgY29va2llLCBidXQgbW9kaWZ5IHRoZSByZXF1aXJlZCBudW1i ZXIgb2YgemVybyBiaXRzCiAgIHRvIDIyLiAgVGhlIGZpcnN0IDQtb2N0ZXQga2V5cyB0aGF0 IHdvcmsgdG8gc2F0aXNmeSB0aGF0IHJlcXVpcmVtZW50CiAgIGFyZSAwMDVkOWU1NywgMDEw ZDg5NTksIDAxMTA3NzhkLCBhbmQgMDExODdlMzcuICBGaW5kaW5nIHRoZXNlCiAgIHJlcXVp cmVzIDE4LDM4MiwzOTIgaW52b2NhdGlvbnMgb2YgdGhlIFBSRi4KCiAgICAgICAgICAgICAg ICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAg ICAgICAgIHwgIyAwLWJpdHMgfCBUaW1lIHRvIEZpbmQgNCBrZXlzIChzZWNvbmRzKSB8CiAg ICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCiAgICAgICAgICAgICAgIHwgICAgOCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg IDAuMDAyNSB8CiAgICAgICAgICAgICAgIHwgICAgMTAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIDAuMDA3OCB8CiAgICAgICAgICAgICAgIHwgICAgMTIgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgIDAuMDUzMCB8CiAgICAgICAgICAgICAgIHwgICAgMTQgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIDAuMjUyMSB8CiAgICAgICAgICAgICAgIHwgICAgMTYgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIDAuODUwNCB8CiAgICAgICAgICAgICAgIHwgICAg MTcgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDEuNTkzOCB8CiAgICAgICAgICAgICAg IHwgICAgMTggICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDMuMzg0MiB8CiAgICAgICAg ICAgICAgIHwgICAgMTkgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIDMuODU5MiB8CiAg ICAgICAgICAgICAgIHwgICAgMjAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgMTAuODg3 NiB8CiAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogIFRhYmxl IDI6IFRoZSB0aW1lIG5lZWRlZCB0byBzb2x2ZSBhIHB1enpsZSBvZiB2YXJpb3VzIGRpZmZp Y3VsdHkgZm9yCiAgIHRoZSBjb29raWUgPSA3MzlhZTc0OTJkOGE4MTBjZjVlOGRjMGY5NjI2 YzlkZGE3NzNjNWEzCgogICBUaGUgZmlndXJlcyBhYm92ZSB3ZXJlIG9idGFpbmVkIG9uIGEg Mi40IEdIeiBzaW5nbGUgY29yZSBpNS4gIFJ1bgogICB0aW1lcyBjYW4gYmUgaGFsdmVkIG9y IHF1YXJ0ZXJlZCB3aXRoIG11bHRpLWNvcmUgY29kZSwgYnV0IHdvdWxkIGJlCiAgIGxvbmdl ciBvbiBtb2JpbGUgcGhvbmUgcHJvY2Vzc29ycywgZXZlbiBpZiB0aG9zZSBhcmUgbXVsdGkt Y29yZSBhcwogICB3ZWxsLiAgV2l0aCB0aGVzZSBmaWd1cmVzIDE4IGJpdHMgaXMgYmVsaWV2 ZWQgdG8gYmUgYSByZWFzb25hYmxlCiAgIGNob2ljZSBmb3IgcHV6emxlIGxldmVsIGRpZmZp Y3VsdHkgZm9yIGFsbCBJbml0aWF0b3JzLCBhbmQgMjAgYml0cyBpcwogICBhY2NlcHRhYmxl IGZvciBzcGVjaWZpYyBob3N0cy9wcmVmaXhlcy4KCiAgICA0LiAgUmV0ZW50aW9uIFBlcmlv ZHMgZm9yIEhhbGYtT3BlbiBTQXMKCiAgIEFzIGEgVURQLWJhc2VkIHByb3RvY29sLCBJS0V2 MiBoYXMgdG8gZGVhbCB3aXRoIHBhY2tldCBsb3NzIHRocm91Z2gKICAgcmV0cmFuc21pc3Np b25zLiAgU2VjdGlvbiAyLjQgb2YgW1JGQzcyOTZdIHJlY29tbWVuZHMgInRoYXQgbWVzc2Fn ZXMKICAgYmUgcmV0cmFuc21pdHRlZCBhdCBsZWFzdCBhIGRvemVuIHRpbWVzIG92ZXIgYSBw ZXJpb2Qgb2YgYXQgbGVhc3QKICAgc2V2ZXJhbCBtaW51dGVzIGJlZm9yZSBnaXZpbmcgdXAi LiAgUmV0cmFuc21pc3Npb24gcG9saWNpZXMgaW4KICAgcHJhY3RpY2Ugd2FpdCBhdCBsZWFz dCBvbmUgb3IgdHdvIHNlY29uZHMgYmVmb3JlIHJldHJhbnNtaXR0aW5nIGZvcgogICB0aGUg Zmlyc3QgdGltZS4KIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVt YmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAx NgoKCiAgIEJlY2F1c2Ugb2YgdGhpcywgc2V0dGluZyB0aGUgdGltZW91dCBvbiBhIGhhbGYt b3BlbiBTQSB0b28gbG93IHdpbGwKICAgY2F1c2UgaXQgdG8gZXhwaXJlIHdoZW5ldmVyIGV2 ZW4gb25lIElLRV9BVVRIIHJlcXVlc3QgcGFja2V0IGlzIGxvc3QuCiAgIFdoZW4gbm90IHVu ZGVyIGF0dGFjaywgdGhlIGhhbGYtb3BlbiBTQSB0aW1lb3V0IFNIT1VMRCBiZSBzZXQgaGln aAogICBlbm91Z2ggdGhhdCB0aGUgSW5pdGlhdG9yIHdpbGwgaGF2ZSBlbm91Z2ggdGltZSB0 byBzZW5kIG11bHRpcGxlCiAgIHJldHJhbnNtaXNzaW9ucywgbWluaW1pemluZyB0aGUgY2hh bmNlIG9mIHRyYW5zaWVudCBuZXR3b3JrCiAgIGNvbmdlc3Rpb24gY2F1c2luZyBJS0UgZmFp bHVyZS4KCiAgIFdoZW4gdGhlIHN5c3RlbSBpcyB1bmRlciBhdHRhY2ssIGFzIG1lYXN1cmVk IGJ5IHRoZSBhbW91bnQgb2YgaGFsZi0KICAgb3BlbiBTQXMsIGl0IG1ha2VzIHNlbnNlIHRv IHJlZHVjZSB0aGlzIGxpZmV0aW1lLiAgVGhlIFJlc3BvbmRlcgogICBzaG91bGQgc3RpbGwg YWxsb3cgZW5vdWdoIHRpbWUgZm9yIHRoZSByb3VuZC10cmlwLCBlbm91Z2ggdGltZSBmb3IK ICAgdGhlIEluaXRpYXRvciB0byBkZXJpdmUgdGhlIEQtSCBzaGFyZWQgdmFsdWUsIGFuZCBl bm91Z2ggdGltZSB0bwogICBkZXJpdmUgdGhlIElLRSBTQSBrZXlzIGFuZCB0aGUgY3JlYXRl IHRoZSBJS0VfQVVUSCByZXF1ZXN0LiAgVHdvCiAgIHNlY29uZHMgaXMgcHJvYmFibHkgYXMg bG93IGEgdmFsdWUgYXMgY2FuIHJlYWxpc3RpY2FsbHkgYmUgdXNlZC4KCiAgIEl0IGNvdWxk IG1ha2Ugc2Vuc2UgdG8gYXNzaWduIGEgc2hvcnRlciB2YWx1ZSB0byBoYWxmLW9wZW4gU0Fz CiAgIG9yaWdpbmF0aW5nIGZyb20gSVAgYWRkcmVzc2VzIG9yIHByZWZpeGVzIHRoYXQgYXJl IGNvbnNpZGVyZWQgc3VzcGVjdAogICBiZWNhdXNlIG9mIG11bHRpcGxlIGNvbmN1cnJlbnQg aGFsZi1vcGVuIFNBcy4KCiAgICA1LiAgUmF0ZSBMaW1pdGluZwoKICAgRXZlbiB3aXRoIERE b1MsIHRoZSBhdHRhY2tlciBoYXMgb25seSBhIGxpbWl0ZWQgYW1vdW50IG9mIG5vZGVzCiAg IHBhcnRpY2lwYXRpbmcgaW4gdGhlIGF0dGFjay4gIEJ5IGxpbWl0aW5nIHRoZSBhbW91bnQg b2YgaGFsZi1vcGVuIFNBcwogICB0aGF0IGFyZSBhbGxvd2VkIHRvIGV4aXN0IGNvbmN1cnJl bnRseSB3aXRoIGVhY2ggc3VjaCBub2RlLCB0aGUgdG90YWwKICAgYW1vdW50IG9mIGhhbGYt b3BlbiBTQXMgaXMgY2FwcGVkLCBhcyBpcyB0aGUgdG90YWwgYW1vdW50IG9mIGtleQogICBk ZXJpdmF0aW9ucyB0aGF0IHRoZSBSZXNwb25kZXIgaXMgZm9yY2VkIHRvIGNvbXBsZXRlLgoK ICAgSW4gSVB2NCBpdCBtYWtlcyBzZW5zZSB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIGhhbGYt b3BlbiBTQXMgYmFzZWQgb24KICAgSVAgYWRkcmVzcy4gIE1vc3QgSVB2NCBub2RlcyBhcmUg ZWl0aGVyIGRpcmVjdGx5IGF0dGFjaGVkIHRvIHRoZQogICBJbnRlcm5ldCB1c2luZyBhIHJv dXRhYmxlIGFkZHJlc3Mgb3IgYXJlIGhpZGRlbiBiZWhpbmQgYSBOQVQgZGV2aWNlCiAgIHdp dGggYSBzaW5nbGUgSVB2NCBleHRlcm5hbCBhZGRyZXNzLiAgSVB2NiBuZXR3b3JrcyBhcmUg Y3VycmVudGx5IGEKICAgcmFyaXR5LCBzbyB3ZSBjYW4gb25seSBzcGVjdWxhdGUgb24gd2hh dCB0aGVpciB3aWRlIGRlcGxveW1lbnQgd2lsbAogICBiZSBsaWtlLCBidXQgdGhlIGN1cnJl bnQgdGhpbmtpbmcgaXMgdGhhdCBJU1AgY3VzdG9tZXJzIHdpbGwgYmUKICAgYXNzaWduZWQg d2hvbGUgc3VibmV0cywgc28gd2UgZG9uJ3QgZXhwZWN0IHRoZSBraW5kIG9mIE5BVCBkZXBs b3ltZW50CiAgIHRoYXQgaXMgY29tbW9uIGluIElQdjQuICBGb3IgdGhpcyByZWFzb24sIGl0 IG1ha2VzIHNlbnNlIHRvIHVzZSBhCiAgIDY0LWJpdCBwcmVmaXggYXMgdGhlIGJhc2lzIGZv ciByYXRlIGxpbWl0aW5nIGluIElQdjYuCgogICBUaGUgbnVtYmVyIG9mIGhhbGYtb3BlbiBT QXMgaXMgZWFzeSB0byBtZWFzdXJlLCBidXQgaXQgaXMgYWxzbwogICB3b3J0aHdoaWxlIHRv IG1lYXN1cmUgdGhlIG51bWJlciBvZiBmYWlsZWQgSUtFX0FVVEggZXhjaGFuZ2VzLiAgSWYK ICAgcG9zc2libGUsIGJvdGggZmFjdG9ycyBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50 IHdoZW4gZGVjaWRpbmcKICAgd2hpY2ggSVAgYWRkcmVzcyBvciBwcmVmaXggaXMgY29uc2lk ZXJlZCBzdXNwaWNpb3VzLgoKICAgVGhlcmUgYXJlIHR3byB3YXlzIHRvIHJhdGUtbGltaXQg YSBwZWVyIGFkZHJlc3Mgb3IgcHJlZml4OgoKICAgICAgIDEuICBIYXJkIExpbWl0IC0gd2hl cmUgdGhlIG51bWJlciBvZiBoYWxmLW9wZW4gU0FzIGlzIGNhcHBlZCwgYW5kCiAgICAgICBh bnkgZnVydGhlciBJS0VfU0FfSU5JVCByZXF1ZXN0cyBhcmUgcmVqZWN0ZWQuCgoKCiAKCgpO aXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAg ICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVj dGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICAyLiAgU29mdCBM aW1pdCAtIHdoZXJlIGlmIGEgc2V0IG51bWJlciBvZiBoYWxmLW9wZW4gU0FzIGV4aXN0IGZv ciBhCiAgICAgICBwYXJ0aWN1bGFyIGFkZHJlc3Mgb3IgcHJlZml4LCBhbnkgSUtFX1NBX0lO SVQgcmVxdWVzdCB3aWxsCiAgICAgICByZXF1aXJlIHNvbHZpbmcgYSBwdXp6bGUuCgogICBU aGUgYWR2YW50YWdlIG9mIHRoZSBoYXJkIGxpbWl0IG1ldGhvZCBpcyB0aGF0IGl0IHByb3Zp ZGVzIGEgaGFyZCBjYXAKICAgb24gdGhlIGFtb3VudCBvZiBoYWxmLW9wZW4gU0FzIHRoYXQg dGhlIGF0dGFja2VyIGlzIGFibGUgdG8gY3JlYXRlLgogICBUaGUgZG93bnNpZGUgaXMgdGhh dCBpdCBhbGxvd3MgdGhlIGF0dGFja2VyIHRvIGJsb2NrIElLRSBpbml0aWF0aW9uCiAgIGZy b20gc21hbGwgcGFydHMgb2YgdGhlIEludGVybmV0LiAgRm9yIGV4YW1wbGUsIGlmIGFuIG5l dHdvcmsgc2VydmljZQogICBwcm92aWRlciBvciBzb21lIGVzdGFibGlzaG1lbnQgb2ZmZXJz IEludGVybmV0IGNvbm5lY3Rpdml0eSB0byBpdHMKICAgY3VzdG9tZXJzIG9yIGVtcGxveWVl cyB0aHJvdWdoIGFuIElQdjQgTkFUIGRldmljZSwgYSBzaW5nbGUgbWFsaWNpb3VzCiAgIGN1 c3RvbWVyIGNhbiBjcmVhdGUgZW5vdWdoIGhhbGYtb3BlbiBTQXMgdG8gZmlsbCB0aGUgcXVv dGEgZm9yIHRoZQogICBOQVQgZGV2aWNlIGV4dGVybmFsIElQIGFkZHJlc3MuICBMZWdpdGlt YXRlIEluaXRpYXRvcnMgb24gdGhlIHNhbWUKICAgbmV0d29yayB3aWxsIG5vdCBiZSBhYmxl IHRvIGluaXRpYXRlIElLRS4KCiAgIFRoZSBhZHZhbnRhZ2Ugb2YgYSBzb2Z0IGxpbWl0IGlz IHRoYXQgbGVnaXRpbWF0ZSBjbGllbnRzIGNhbiBhbHdheXMKICAgY29ubmVjdC4gIFRoZSBk aXNhZHZhbnRhZ2UgaXMgdGhhdCBhbiBhZHZlcnNhcnkgd2l0aCBzdWZmaWNpZW50IENQVQog ICByZXNvdXJjZXMgY2FuIHN0aWxsIGVmZmVjdGl2ZWx5IERvUyB0aGUgUmVzcG9uZGVyLgoK ICAgUmVnYXJkbGVzcyBvZiB0aGUgdHlwZSBvZiByYXRlLWxpbWl0aW5nIHVzZWQsIHRoZXJl IGlzIGEgaHVnZQogICBhZHZhbnRhZ2UgaW4gYmxvY2tpbmcgdGhlIERvUyBhdHRhY2sgdXNp bmcgcmF0ZS1saW1pdGluZyBmb3IKICAgbGVnaXRpbWF0ZSBjbGllbnRzIHRoYXQgYXJlIGF3 YXkgZnJvbSB0aGUgYXR0YWNraW5nIG5vZGVzLiAgSW4gc3VjaAogICBjYXNlcywgYWR2ZXJz ZSBpbXBhY3RzIGNhdXNlZCBieSB0aGUgYXR0YWNrIG9yIGJ5IHRoZSBtZWFzdXJlcyB1c2Vk CiAgIHRvIGNvdW50ZXJhY3QgdGhlIGF0dGFjayBjYW4gYmUgYXZvaWRlZC4KCiAgICA2LiAg UGxhbiBmb3IgRGVmZW5kaW5nIGEgUmVzcG9uZGVyCgogICBUaGlzIHNlY3Rpb24gb3V0bGlu ZXMgYSBwbGFuIGZvciBkZWZlbmRpbmcgYSBSZXNwb25kZXIgZnJvbSBhIEREb1MKICAgYXR0 YWNrIGJhc2VkIG9uIHRoZSB0ZWNobmlxdWVzIGRlc2NyaWJlZCBlYXJsaWVyLiAgVGhlIG51 bWJlcnMgZ2l2ZW4KICAgaGVyZSBhcmUgbm90IG5vcm1hdGl2ZSwgYW5kIHRoZWlyIHB1cnBv c2UgaXMgdG8gaWxsdXN0cmF0ZSB0aGUKICAgY29uZmlndXJhYmxlIHBhcmFtZXRlcnMgbmVl ZGVkIGZvciBkZWZlYXRpbmcgdGhlIEREb1MgYXR0YWNrLgoKICAgSW1wbGVtZW50YXRpb25z IG1heSBiZSBkZXBsb3llZCBpbiBkaWZmZXJlbnQgZW52aXJvbm1lbnRzLCBzbyBpdCBpcwog ICBSRUNPTU1FTkRFRCB0aGF0IHRoZSBwYXJhbWV0ZXJzIGJlIHNldHRhYmxlLiAgQXMgYW4g ZXhhbXBsZSwgbW9zdAogICBjb21tZXJjaWFsIHByb2R1Y3RzIGFyZSByZXF1aXJlZCB0byB1 bmRlcmdvIGJlbmNobWFya2luZyB3aGVyZSB0aGUKICAgSUtFIFNBIGVzdGFibGlzaG1lbnQg cmF0ZSBpcyBtZWFzdXJlZC4gIEJlbmNobWFya2luZyBpcwogICBpbmRpc3Rpbmd1aXNoYWJs ZSBmcm9tIGEgRG9TIGF0dGFjayBhbmQgdGhlIGRlZmVuc2VzIGRlc2NyaWJlZCBpbgogICB0 aGlzIGRvY3VtZW50IG1heSBkZWZlYXQgdGhlIGJlbmNobWFyayBieSBjYXVzaW5nIGV4Y2hh bmdlcyB0byBmYWlsCiAgIG9yIHRha2UgYSBsb25nIHRpbWUgdG8gY29tcGxldGUuICBQYXJh bWV0ZXJzIHNob3VsZCBiZSB0dW5hYmxlIHRvCiAgIGFsbG93IGZvciBiZW5jaG1hcmtpbmcg KGlmIG9ubHkgYnkgdHVybmluZyBERG9TIHByb3RlY3Rpb24gb2ZmKS4KCiAgIFNpbmNlIGFs bCBjb3VudGVybWVhc3VyZXMgbWF5IGNhdXNlIGRlbGF5cyBhbmQgd29yayBvbiB0aGUKICAg SW5pdGlhdG9ycywgdGhleSBTSE9VTEQgTk9UIGJlIGRlcGxveWVkIHVubGVzcyBhbiBhdHRh Y2sgaXMgbGlrZWx5IHRvCiAgIGJlIGluIHByb2dyZXNzLiAgVG8gbWluaW1pemUgdGhlIGJ1 cmRlbiBpbXBvc2VkIG9uIEluaXRpYXRvcnMsIHRoZQogICBSZXNwb25kZXIgc2hvdWxkIG1v bml0b3IgaW5jb21pbmcgSUtFIHJlcXVlc3RzLCBzZWFyY2hpbmcgZm9yIHR3bwogICB0aGlu Z3M6CgogICAgICAgMS4gIEEgZ2VuZXJhbCBERG9TIGF0dGFjay4gIFN1Y2ggYW4gYXR0YWNr IGlzIGluZGljYXRlZCBieSBhIGhpZ2gKICAgICAgIG51bWJlciBvZiBjb25jdXJyZW50IGhh bGYtb3BlbiBTQXMsIGEgaGlnaCByYXRlIG9mIGZhaWxlZAogCgoKTmlyICYgU215c2xvdiAm IEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2Ug MTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYy ICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgICAgIElLRV9BVVRIIGV4Y2hhbmdlcywg b3IgYSBjb21iaW5hdGlvbiBvZiBib3RoLiAgRm9yIGV4YW1wbGUsCiAgICAgICBjb25zaWRl ciBhIFJlc3BvbmRlciB0aGF0IGhhcyAxMCwwMDAgZGlzdGluY3QgcGVlcnMgb2Ygd2hpY2gg YXQKICAgICAgIHBlYWsgNyw1MDAgY29uY3VycmVudGx5IGhhdmUgVlBOIHR1bm5lbHMuICBB dCB0aGUgc3RhcnQgb2YgcGVhawogICAgICAgdGltZSwgNjAwIHBlZXJzIG1pZ2h0IGVzdGFi bGlzaCB0dW5uZWxzIGF0IGFueSBnaXZlbiBtaW51dGUsIGFuZAogICAgICAgdHVubmVsIGVz dGFibGlzaG1lbnQgKGJvdGggSUtFX1NBX0lOSVQgYW5kIElLRV9BVVRIKSB0YWtlcwogICAg ICAgYW55d2hlcmUgZnJvbSAwLjUgdG8gMiBzZWNvbmRzLiAgRm9yIHRoaXMgUmVzcG9uZGVy LCB3ZSBleHBlY3QKICAgICAgIHRoZXJlIHRvIGJlIGxlc3MgdGhhbiAyMCBjb25jdXJyZW50 IGhhbGYtb3BlbiBTQXMsIHNvIGhhdmluZyAxMDAKICAgICAgIGNvbmN1cnJlbnQgaGFsZi1v cGVuIFNBcyBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYW4gaW5kaWNhdGlvbiBvZgogICAgICAg YW4gYXR0YWNrLiAgU2ltaWxhcmx5LCBJS0VfQVVUSCByZXF1ZXN0IGRlY3J5cHRpb24gZmFp bHVyZXMKICAgICAgIHNob3VsZCBuZXZlciBoYXBwZW4uICBTdXBwb3NpbmcgdGhlIHRoZSB0 dW5uZWxzIGFyZSBlc3RhYmxpc2hlZAogICAgICAgdXNpbmcgRUFQIChzZWUgU2VjdGlvbiAy LjE2IG9mIFtSRkM3Mjk2XSksIHVzZXJzIGVudGVyIHRoZSB3cm9uZwogICAgICAgcGFzc3dv cmQgYWJvdXQgMjAlIG9mIHRoZSB0aW1lLiAgU28gd2UnZCBleHBlY3QgMTI1IHdyb25nCiAg ICAgICBwYXNzd29yZCBmYWlsdXJlcyBhIG1pbnV0ZS4gIElmIHdlIGdldCBJS0VfQVVUSCBk ZWNyeXB0aW9uCiAgICAgICBmYWlsdXJlcyBmcm9tIG11bHRpcGxlIHNvdXJjZXMgbW9yZSB0 aGFuIG9uY2UgcGVyIHNlY29uZCwgb3IgRUFQCiAgICAgICBmYWlsdXJlIG1vcmUgdGhhbiAz MDAgdGltZXMgcGVyIG1pbnV0ZSwgdGhhdCBjYW4gYWxzbyBiZSBhbgogICAgICAgaW5kaWNh dGlvbiBvZiBhIEREb1MgYXR0YWNrLgoKICAgICAgIDIuICBBbiBhdHRhY2sgZnJvbSBhIHBh cnRpY3VsYXIgSVAgYWRkcmVzcyBvciBwcmVmaXguICBTdWNoIGFuCiAgICAgICBhdHRhY2sg aXMgaW5kaWNhdGVkIGJ5IGFuIGlub3JkaW5hdGUgYW1vdW50IG9mIGhhbGYtb3BlbiBTQXMg ZnJvbQogICAgICAgdGhhdCBJUCBhZGRyZXNzIG9yIHByZWZpeCwgb3IgYW4gaW5vcmRpbmF0 ZSBhbW91bnQgb2YgSUtFX0FVVEgKICAgICAgIGZhaWx1cmVzLiAgQSBERG9TIGF0dGFjayBt YXkgYmUgdmlld2VkIGFzIG11bHRpcGxlIHN1Y2ggYXR0YWNrcy4KICAgICAgIElmIHRoZXkg YXJlIG1pdGlnYXRlZCB3ZWxsIGVub3VnaCwgdGhlcmUgd2lsbCBub3QgYmUgYSBuZWVkIGVu YWN0CiAgICAgICBjb3VudGVybWVhc3VyZXMgb24gYWxsIEluaXRpYXRvcnMuICBUeXBpY2Fs IG1lYXN1cmVzIG1pZ2h0IGJlIDUKICAgICAgIGNvbmN1cnJlbnQgaGFsZi1vcGVuIFNBcywg MSBkZWNyeXB0IGZhaWx1cmUsIG9yIDEwIEVBUCBmYWlsdXJlcwogICAgICAgd2l0aGluIGEg bWludXRlLgoKICAgTm90ZSB0aGF0IHVzaW5nIGNvdW50ZXItbWVhc3VyZXMgYWdhaW5zdCBh biBhdHRhY2sgZnJvbSBhIHBhcnRpY3VsYXIKICAgSVAgYWRkcmVzcyBtYXkgYmUgZW5vdWdo IHRvIGF2b2lkIHRoZSBvdmVybG9hZCBvbiB0aGUgaGFsZi1vcGVuIFNBCiAgIGRhdGFiYXNl IGFuZCBpbiB0aGlzIGNhc2UgdGhlIG51bWJlciBvZiBmYWlsZWQgSUtFX0FVVEggZXhjaGFu Z2VzCiAgIG5ldmVyIGV4Y2VlZHMgdGhlIHRocmVzaG9sZCBvZiBhdHRhY2sgZGV0ZWN0aW9u LiAgVGhpcyBpcyBhIGdvb2QKICAgdGhpbmcgYXMgaXQgcHJldmVudHMgSW5pdGlhdG9ycyB0 aGF0IGFyZSBub3QgY2xvc2UgdG8gdGhlIGF0dGFja2VycwogICBmcm9tIGJlaW5nIGFmZmVj dGVkLgoKICAgV2hlbiB0aGVyZSBpcyBubyBnZW5lcmFsIEREb1MgYXR0YWNrLCBpdCBpcyBz dWdnZXN0ZWQgdGhhdCBubyBjb29raWUKICAgb3IgcHV6emxlcyBiZSB1c2VkLiAgQXQgdGhp cyBwb2ludCB0aGUgb25seSBkZWZlbnNpdmUgbWVhc3VyZSBpcyB0aGUKICAgbW9uaXRvcmlu ZyBvZiB0aGUgbnVtYmVyIG9mIGhhbGYtb3BlbiBTQXMsIGFuZCBzZXR0aW5nIGEgc29mdCBs aW1pdAogICBwZXIgcGVlciBJUCBvciBwcmVmaXguICBUaGUgc29mdCBsaW1pdCBjYW4gYmUg c2V0IHRvIDMtNSwgYW5kIHRoZQogICBwdXp6bGUgZGlmZmljdWx0eSBzaG91bGQgYmUgc2V0 IHRvIHN1Y2ggYSBsZXZlbCAobnVtYmVyIG9mIHplcm8tYml0cykKICAgdGhhdCBhbGwgbGVn aXRpbWF0ZSBjbGllbnRzIGNhbiBoYW5kbGUgaXQgd2l0aG91dCBkZWdyYWRlZCB1c2VyCiAg IGV4cGVyaWVuY2UuCgogICBBcyBzb29uIGFzIGFueSBraW5kIG9mIGF0dGFjayBpcyBkZXRl Y3RlZCwgZWl0aGVyIGEgbG90IG9mCiAgIGluaXRpYXRpb25zIGZyb20gbXVsdGlwbGUgc291 cmNlcyBvciBhIGxvdCBvZiBpbml0aWF0aW9ucyBmcm9tIGEgZmV3CiAgIHNvdXJjZXMsIGl0 IGlzIGJlc3QgdG8gYmVnaW4gYnkgcmVxdWlyaW5nIHN0YXRlbGVzcyBjb29raWVzIGZyb20g YWxsCiAgIEluaXRpYXRvcnMuICBUaGlzIHdpbGwgZm9yY2UgdGhlIGF0dGFja2VyIHRvIHVz ZSByZWFsIHNvdXJjZQogICBhZGRyZXNzZXMsIGFuZCBoZWxwIGF2b2lkIHRoZSBuZWVkIHRv IGltcG9zZSBhIGdyZWF0ZXIgYnVyZGVuIGluIHRoZQogICBmb3JtIG9mIGNvb2tpZXMgb24g dGhlIGdlbmVyYWwgcG9wdWxhdGlvbiBvZiBJbml0aWF0b3JzLiAgVGhpcyBtYWtlcwogICB0 aGUgcGVyLW5vZGUgb3IgcGVyLXByZWZpeCBzb2Z0IGxpbWl0IG1vcmUgZWZmZWN0aXZlLgog CgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFBy b3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgV2hlbiBj b29raWVzIGFyZSBhY3RpdmF0ZWQgZm9yIGFsbCByZXF1ZXN0cyBhbmQgdGhlIGF0dGFja2Vy IGlzIHN0aWxsCiAgIG1hbmFnaW5nIHRvIGNvbnN1bWUgdG9vIG1hbnkgcmVzb3VyY2VzLCB0 aGUgUmVzcG9uZGVyIE1BWSBpbmNyZWFzZQogICB0aGUgZGlmZmljdWx0eSBvZiBwdXp6bGVz IGltcG9zZWQgb24gSUtFX1NBX0lOSVQgcmVxdWVzdHMgY29taW5nIGZyb20KICAgc3VzcGlj aW91cyBub2Rlcy9wcmVmaXhlcy4gIEl0IHNob3VsZCBzdGlsbCBiZSBkb2FibGUgYnkgYWxs CiAgIGxlZ2l0aW1hdGUgcGVlcnMsIGJ1dCBpdCBjYW4gZGVncmFkZSBleHBlcmllbmNlLCBm b3IgZXhhbXBsZSBieQogICB0YWtpbmcgdXAgdG8gMTAgc2Vjb25kcyB0byBzb2x2ZSB0aGUg cHV6emxlLgoKICAgSWYgdGhlIGxvYWQgb24gdGhlIFJlc3BvbmRlciBpcyBzdGlsbCB0b28g Z3JlYXQsIGFuZCB0aGVyZSBhcmUgbWFueQogICBub2RlcyBjYXVzaW5nIG11bHRpcGxlIGhh bGYtb3BlbiBTQXMgb3IgSUtFX0FVVEggZmFpbHVyZXMsIHRoZQogICBSZXNwb25kZXIgTUFZ IGltcG9zZSBoYXJkIGxpbWl0cyBvbiB0aG9zZSBub2Rlcy4KCiAgIElmIGl0IHR1cm5zIG91 dCB0aGF0IHRoZSBhdHRhY2sgaXMgdmVyeSB3aWRlc3ByZWFkIGFuZCB0aGUgaGFyZCBjYXBz CiAgIGFyZSBub3Qgc29sdmluZyB0aGUgaXNzdWUsIGEgcHV6emxlIE1BWSBiZSBpbXBvc2Vk IG9uIGFsbCBJbml0aWF0b3JzLgogICBOb3RlIHRoYXQgdGhpcyBpcyB0aGUgbGFzdCBzdGVw LCBhbmQgdGhlIFJlc3BvbmRlciBzaG91bGQgYXZvaWQgdGhpcwogICBpZiBwb3NzaWJsZS4K CiAgICAgIDYuMS4gIFNlc3Npb24gUmVzdW1wdGlvbgoKICAgV2hlbiB0aGUgUmVzcG9uZGVy IGlzIHVuZGVyIGF0dGFjaywgaXQgTUFZIGNob29zZSB0byBwcmVmZXIKICAgcHJldmlvdXNs eSBhdXRoZW50aWNhdGVkIHBlZXJzIHdobyBwcmVzZW50IGEgU2Vzc2lvbiBSZXN1bXB0aW9u CiAgIHRpY2tldCAoc2VlIFtSRkM1NzIzXSBmb3IgZGV0YWlscykuICBUaGUgUmVzcG9uZGVy IE1BWSByZXF1aXJlIHN1Y2gKICAgSW5pdGlhdG9ycyB0byBwYXNzIGEgcmV0dXJuIHJvdXRh YmlsaXR5IGNoZWNrIGJ5IGluY2x1ZGluZyB0aGUgQ09PS0lFCiAgIG5vdGlmaWNhdGlvbiBp biB0aGUgSUtFX1NFU1NJT05fUkVTVU1FIHJlc3BvbnNlIG1lc3NhZ2UsIGFzIGFsbG93ZWQK ICAgYnkgU2VjdGlvbiA0LjMuMi4gb2YgW1JGQzU3MjNdLiAgTm90ZSB0aGF0IHRoZSBSZXNw b25kZXIgU0hPVUxEIGNhY2hlCiAgIHRpY2tldHMgZm9yIGEgc2hvcnQgdGltZSB0byByZWpl Y3QgcmV1c2VkIHRpY2tldHMgKFNlY3Rpb24gNC4zLjEpLAogICBhbmQgdGhlcmVmb3JlIHRo ZXJlIHNob3VsZCBiZSBubyBpc3N1ZSBvZiBoYWxmLW9wZW4gU0FzIHJlc3VsdGluZwogICBm cm9tIHJlcGxheWVkIElLRV9TRVNTSU9OX1JFU1VNRSBtZXNzYWdlcy4KCiAgICA3LiAgVXNp bmcgUHV6emxlcyBpbiB0aGUgUHJvdG9jb2wKCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMg aG93IHRoZSBwdXp6bGUgbWVjaGFuaXNtIGlzIHVzZWQgaW4gSUtFdjIuICBJdAogICBpcyBv cmdhbml6ZWQgYXMgZm9sbG93cy4gIFRoZSBTZWN0aW9uIDcuMSBkZXNjcmliZXMgdXNpbmcg cHV6emxlcyBpbgogICB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UgYW5kIHRoZSBTZWN0aW9u IDcuMiBkZXNjcmliZXMgdXNpbmcgcHV6emxlcwogICBpbiB0aGUgSUtFX0FVVEggZXhjaGFu Z2UuICBCb3RoIHNlY3Rpb25zIGFyZSBkaXZpZGVkIGludG8gc3Vic2VjdGlvbnMKICAgZGVz Y3JpYmluZyBob3cgcHV6emxlcyBzaG91bGQgYmUgcHJlc2VudGVkLCBzb2x2ZWQgYW5kIHBy b2Nlc3NlZCBieQogICB0aGUgSW5pdGlhdG9yIGFuZCB0aGUgUmVzcG9uZGVyLgoKICAgICAg Ny4xLiAgUHV6emxlcyBpbiBJS0VfU0FfSU5JVCBFeGNoYW5nZQoKICAgSUtFIEluaXRpYXRv ciBpbmRpY2F0ZXMgdGhlIGRlc2lyZSB0byBjcmVhdGUgYSBuZXcgSUtFIFNBIGJ5IHNlbmRp bmcKICAgSUtFX1NBX0lOSVQgcmVxdWVzdCBtZXNzYWdlLiAgVGhlIG1lc3NhZ2UgbWF5IG9w dGlvbmFsbHkgY29udGFpbiBhCiAgIENPT0tJRSBub3RpZmljYXRpb24gaWYgdGhpcyBpcyBh IHJlcGVhdGVkIHJlcXVlc3QgcGVyZm9ybWVkIGFmdGVyIHRoZQogICBSZXNwb25kZXIncyBk ZW1hbmQgdG8gcmV0dXJuIGEgY29va2llLgoKICAgSERSLCBbTihDT09LSUUpLF0gU0EsIEtF LCBOaSwgW1YrXVtOK10gICAtLT4KCiAgIEFjY29yZGluZyB0byB0aGUgcGxhbiwgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNiwgdGhlIElLRSBSZXNwb25kZXIKICAgc2hvdWxkIG1vbml0b3Ig aW5jb21pbmcgcmVxdWVzdHMgdG8gZGV0ZWN0IHdoZXRoZXIgaXQgaXMgdW5kZXIKIAoKCk5p ciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAg ICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0 aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIGF0dGFjay4gIElm IHRoZSBSZXNwb25kZXIgbGVhcm5zIHRoYXQgKEQpRG9TIGF0dGFjayBpcyBsaWtlbHkgdG8g YmUKICAgaW4gcHJvZ3Jlc3MsIHRoZW4gaXRzIGFjdGlvbnMgZGVwZW5kIG9uIHRoZSB2b2x1 bWUgb2YgdGhlIGF0dGFjay4gIElmCiAgIHRoZSB2b2x1bWUgaXMgbW9kZXJhdGUsIHRoZW4g dGhlIFJlc3BvbmRlciByZXF1ZXN0cyB0aGUgSW5pdGlhdG9yIHRvCiAgIHJldHVybiBhIGNv b2tpZS4gIElmIHRoZSB2b2x1bWUgaXMgc28gaGlnaCwgdGhhdCBwdXp6bGVzIG5lZWQgdG8g YmUKICAgdXNlZCBmb3IgZGVmZW5zZSwgdGhlbiB0aGUgUmVzcG9uZGVyIHJlcXVlc3RzIHRo ZSBJbml0aWF0b3IgdG8gc29sdmUKICAgYSBwdXp6bGUuCgogICBUaGUgUmVzcG9uZGVyIE1B WSBjaG9vc2UgdG8gcHJvY2VzcyBzb21lIGZyYWN0aW9uIG9mIElLRV9TQV9JTklUCiAgIHJl cXVlc3RzIHdpdGhvdXQgcHJlc2VudGluZyBhIHB1enpsZSB3aGlsZSBiZWluZyB1bmRlciBh dHRhY2sgdG8KICAgYWxsb3cgbGVnYWN5IGNsaWVudHMsIHRoYXQgZG9uJ3Qgc3VwcG9ydCBw dXp6bGVzLCB0byBoYXZlIGEgY2hhbmNlIHRvCiAgIGJlIHNlcnZlZC4gIFRoZSBkZWNpc2lv biB3aGV0aGVyIHRvIHByb2Nlc3MgYW55IHBhcnRpY3VsYXIgcmVxdWVzdAogICBtdXN0IGJl IHByb2JhYmlsaXN0aWMsIHdpdGggdGhlIHByb2JhYmlsaXR5IGRlcGVuZGluZyBvbiB0aGUK ICAgUmVzcG9uZGVyJ3MgbG9hZCAoaS5lLiBvbiB0aGUgdm9sdW1lIG9mIGF0dGFjaykuICBU aGUgcmVxdWVzdHMgdGhhdAogICBkb24ndCBjb250YWluIHRoZSBDT09LSUUgbm90aWZpY2F0 aW9uIE1VU1QgTk9UIHBhcnRpY2lwYXRlIGluIHRoaXMKICAgbG90dGVyeS4gIEluIG90aGVy IHdvcmRzLCB0aGUgUmVzcG9uZGVyIG11c3QgZmlyc3QgcGVyZm9ybSByZXR1cm4KICAgcm91 dGFiaWxpdHkgY2hlY2sgYmVmb3JlIGFsbG93aW5nIGFueSBsZWdhY3kgY2xpZW50IHRvIGJl IHNlcnZlZCBpZgogICBpdCBpcyB1bmRlciBhdHRhY2suICBTZWUgU2VjdGlvbiA3LjEuNCBm b3IgZGV0YWlscy4KCiAgICAgICAgNy4xLjEuICBQcmVzZW50aW5nIFB1enpsZQoKICAgSWYg dGhlIFJlc3BvbmRlciBtYWtlcyBhIGRlY2lzaW9uIHRvIHVzZSBwdXp6bGVzLCB0aGVuIGl0 IE1VU1QKICAgaW5jbHVkZSB0d28gbm90aWZpY2F0aW9ucyBpbiBpdHMgcmVzcG9uc2UgbWVz c2FnZSAtIHRoZSBDT09LSUUKICAgbm90aWZpY2F0aW9uIGFuZCB0aGUgUFVaWkxFIG5vdGlm aWNhdGlvbi4gIFRoZSBmb3JtYXQgb2YgdGhlIFBVWlpMRQogICBub3RpZmljYXRpb24gaXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gOS4xLgoKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8LS0gICBIRFIsIE4oQ09PS0lFKSwgTihQVVpaTEUpLCBbVitdW04rXQoKICAgVGhlIHBy ZXNlbmNlIG9mIHRoZXNlIG5vdGlmaWNhdGlvbnMgaW4gYW4gSUtFX1NBX0lOSVQgcmVzcG9u c2UKICAgbWVzc2FnZSBpbmRpY2F0ZXMgdG8gdGhlIEluaXRpYXRvciB0aGF0IGl0IHNob3Vs ZCBzb2x2ZSB0aGUgcHV6emxlIHRvCiAgIGdldCBiZXR0ZXIgY2hhbmNlcyB0byBiZSBzZXJ2 ZWQuCgogICAgICAgICAgNy4xLjEuMS4gIFNlbGVjdGluZyBQdXp6bGUgRGlmZmljdWx0eSBM ZXZlbAoKICAgVGhlIFBVWlpMRSBub3RpZmljYXRpb24gY29udGFpbnMgdGhlIGRpZmZpY3Vs dHkgbGV2ZWwgb2YgdGhlIHB1enpsZSAtCiAgIHRoZSBtaW5pbXVtIG51bWJlciBvZiB0cmFp bGluZyB6ZXJvIGJpdHMgdGhhdCB0aGUgcmVzdWx0IG9mIFBSRiBtdXN0CiAgIGNvbnRhaW4u ICBJbiBkaXZlcnNlIGVudmlyb25tZW50cyBpdCBpcyBuZXh0IHRvIGltcG9zc2libGUgZm9y IHRoZQogICBSZXNwb25kZXIgdG8gc2V0IGFueSBzcGVjaWZpYyBkaWZmaWN1bHR5IGxldmVs IHRoYXQgd2lsbCByZXN1bHQgaW4KICAgcm91Z2hseSB0aGUgc2FtZSBhbW91bnQgb2Ygd29y ayBmb3IgYWxsIEluaXRpYXRvcnMsIGJlY2F1c2UKICAgY29tcHV0YXRpb24gcG93ZXIgb2Yg ZGlmZmVyZW50IEluaXRpYXRvcnMgbWF5IHZhcnkgYnkgdGhlIG9yZGVyIG9mCiAgIG1hZ25p dHVkZSwgb3IgZXZlbiBtb3JlLiAgVGhlIFJlc3BvbmRlciBtYXkgc2V0IGRpZmZpY3VsdHkg bGV2ZWwgdG8KICAgMCwgbWVhbmluZyB0aGF0IHRoZSBJbml0aWF0b3IgaXMgcmVxdWVzdGVk IHRvIHNwZW5kIGFzIG11Y2ggcG93ZXIgdG8KICAgc29sdmUgcHV6emxlLCBhcyBpdCBjYW4g YWZmb3JkLiAgSW4gdGhpcyBjYXNlIG5vIHNwZWNpZmljIHZhbHVlIG9mCiAgIFpCQyBpcyBy ZXF1aXJlZCBmcm9tIHRoZSBJbml0aWF0b3IsIGhvd2V2ZXIgdGhlIGxhcmdlciB0aGUgWkJD IHRoYXQKICAgSW5pdGlhdG9yIGlzIGFibGUgdG8gZ2V0LCB0aGUgYmV0dGVyIHRoZSBjaGFu Y2VzIGl0IHdpbGwgaGF2ZSB0byBiZQogICBzZXJ2ZWQgYnkgdGhlIFJlc3BvbmRlci4gIElu IGRpdmVyc2UgZW52aXJvbm1lbnRzIGl0IGlzIFJFQ09NTUVOREVECiAgIHRoYXQgdGhlIElu aXRpYXRvciBzZXRzIGRpZmZpY3VsdHkgbGV2ZWwgdG8gMCwgdW5sZXNzIHRoZSBhdHRhY2sK ICAgdm9sdW1lIGlzIHZlcnkgaGlnaC4KCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRF eHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAg ICAgIE1hcmNoIDIwMTYKCgogICBJZiB0aGUgUmVzcG9uZGVyIHNldHMgbm9uLXplcm8gZGlm ZmljdWx0eSBsZXZlbCwgdGhlbiB0aGUgbGV2ZWwKICAgc2hvdWxkIGJlIGRldGVybWluZWQg YnkgYW5hbHl6aW5nIHRoZSB2b2x1bWUgb2YgdGhlIGF0dGFjay4gIFRoZQogICBSZXNwb25k ZXIgTUFZIHNldCBkaWZmZXJlbnQgZGlmZmljdWx0eSBsZXZlbHMgdG8gZGlmZmVyZW50IHJl cXVlc3RzCiAgIGRlcGVuZGluZyBvbiB0aGUgSVAgYWRkcmVzcyB0aGUgcmVxdWVzdCBoYXMg Y29tZSBmcm9tLgoKICAgICAgICAgIDcuMS4xLjIuICBTZWxlY3RpbmcgUHV6emxlIEFsZ29y aXRobQoKICAgVGhlIFBVWlpMRSBub3RpZmljYXRpb24gYWxzbyBjb250YWlucyBpZGVudGlm aWVyIG9mIHRoZSBhbGdvcml0aG0sCiAgIHRoYXQgbXVzdCBiZSB1c2VkIGJ5IEluaXRpYXRv ciB0byBjb21wdXRlIHB1enpsZS4KCiAgIENyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIGFnaWxp dHkgaXMgY29uc2lkZXJlZCBhbiBpbXBvcnRhbnQgZmVhdHVyZQogICBmb3IgbW9kZXJuIHBy b3RvY29scyAoW1JGQzc2OTZdKS4gIFRoaXMgZmVhdHVyZSBlbnN1cmVzIHRoYXQgcHJvdG9j b2wKICAgZG9lc24ndCByZWx5IG9uIGEgc2luZ2xlIGJ1aWxkLWluIHNldCBvZiBjcnlwdG9n cmFwaGljIGFsZ29yaXRobXMsCiAgIGJ1dCBoYXMgYSBtZWFucyB0byByZXBsYWNlIG9uZSBz ZXQgd2l0aCBhbm90aGVyIGFuZCBuZWdvdGlhdGUgbmV3IHNldAogICB3aXRoIHRoZSBwZWVy LiAgSUtFdjIgZnVsbHkgc3VwcG9ydHMgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gYWdpbGl0 eQogICBmb3IgaXRzIGNvcmUgb3BlcmF0aW9ucy4KCiAgIFRvIHN1cHBvcnQgdGhpcyBmZWF0 dXJlIGluIGNhc2Ugb2YgcHV6emxlcywgdGhlIGFsZ29yaXRobSB0aGF0IGlzCiAgIHVzZWQg dG8gY29tcHV0ZSBwdXp6bGUgbmVlZHMgdG8gYmUgbmVnb3RpYXRlZCBkdXJpbmcgSUtFX1NB X0lOSVQKICAgZXhjaGFuZ2UuICBUaGUgbmVnb3RpYXRpb24gaXMgcGVyZm9ybWVkIGFzIGZv bGxvd3MuICBUaGUgaW5pdGlhbAogICByZXF1ZXN0IG1lc3NhZ2Ugc2VudCBieSBJbml0aWF0 b3IgY29udGFpbnMgU0EgcGF5bG9hZCB3aXRoIHRoZSBsaXN0CiAgIG9mIHRyYW5zZm9ybXMg dGhlIEluaXRpYXRvciBzdXBwb3J0cyBhbmQgaXMgd2lsbGluZyB0byB1c2UgaW4gdGhlIElL RQogICBTQSBiZWluZyBlc3RhYmxpc2hlZC4gIFRoZSBSZXNwb25kZXIgcGFyc2VzIHJlY2Vp dmVkIFNBIHBheWxvYWQgYW5kCiAgIGZpbmRzIG11dHVhbGx5IHN1cHBvcnRlZCBzZXQgb2Yg dHJhbnNmb3JtcyBvZiB0eXBlIFBSRi4gIEl0IHNlbGVjdHMKICAgbW9zdCBwcmVmZXJyZWQg dHJhbnNmb3JtIGZyb20gdGhpcyBzZXQgYW5kIGluY2x1ZGVzIGl0IGludG8gdGhlCiAgIFBV WlpMRSBub3RpZmljYXRpb24uICBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IHRoZSBQ UkYgc2VsZWN0ZWQKICAgZm9yIHB1enpsZXMgYmUgdGhlIHNhbWUsIGFzIHRoZSBQUkYgdGhh dCBpcyBuZWdvdGlhdGVkIGxhdGVyIGZvciB0aGUKICAgdXNlIGluIGNvcmUgSUtFIFNBIGNy eXB0byBvcGVyYXRpb25zLiAgSWYgdGhlcmUgYXJlIG5vIG11dHVhbGx5CiAgIHN1cHBvcnRl ZCBQUkZzLCB0aGVuIG5lZ290aWF0aW9uIHdpbGwgZmFpbCBhbnl3YXkgYW5kIHRoZXJlIGlz IG5vCiAgIHJlYXNvbiB0byByZXR1cm4gYSBwdXp6bGUuICBJbiB0aGlzIGNhc2UgdGhlIFJl c3BvbmRlciByZXR1cm5zCiAgIE5PX1BST1BPU0FMX0NIT1NFTiBub3RpZmljYXRpb24uICBO b3RlIHRoYXQgUFJGIGlzIGEgbWFuZGF0b3J5CiAgIHRyYW5zZm9ybSB0eXBlIGZvciBJS0Ug U0EgKHNlZSBTZWN0aW9ucyAzLjMuMiBhbmQgMy4zLjMgb2YgW1JGQzcyOTZdKQogICBhbmQg YXQgbGVhc3Qgb25lIHRyYW5zZm9ybSBvZiB0aGlzIHR5cGUgbXVzdCBhbHdheXMgYmUgcHJl c2VudCBpbiBTQQogICBwYXlsb2FkIGluIElLRV9TQV9JTklUIHJlcXVlc3QgbWVzc2FnZS4K CiAgICAgICAgICA3LjEuMS4zLiAgR2VuZXJhdGluZyBDb29raWUKCiAgIElmIFJlc3BvbmRl ciBzdXBwb3J0cyBwdXp6bGVzIHRoZW4gY29va2llIHNob3VsZCBiZSBjb21wdXRlZCBpbiBz dWNoCiAgIGEgbWFubmVyLCB0aGF0IHRoZSBSZXNwb25kZXIgaXMgYWJsZSB0byBsZWFybiBz b21lIGltcG9ydGFudAogICBpbmZvcm1hdGlvbiBmcm9tIHRoZSBzb2xlIGNvb2tpZSwgd2hl biBpdCBpcyBsYXRlciByZXR1cm5lZCBiYWNrIGJ5CiAgIEluaXRpYXRvci4gIEluIHBhcnRp Y3VsYXIgLSB0aGUgUmVzcG9uZGVyIHNob3VsZCBiZSBhYmxlIHRvIGxlYXJuIHRoZQogICBm b2xsb3dpbmcgaW5mb3JtYXRpb246CgogICAgICBvICBXaGV0aGVyIHRoZSBwdXp6bGUgd2Fz IGdpdmVuIHRvIHRoZSBJbml0aWF0b3Igb3Igb25seSB0aGUKICAgICAgY29va2llIHdhcyBy ZXF1ZXN0ZWQuCgogICAgICBvICBUaGUgZGlmZmljdWx0eSBsZXZlbCBvZiB0aGUgcHV6emxl IGdpdmVuIHRvIHRoZSBJbml0aWF0b3IuCgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0 RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAg ICAgICBNYXJjaCAyMDE2CgoKICAgbyAgVGhlIG51bWJlciBvZiBjb25zZWN1dGl2ZSBwdXp6 bGVzIGdpdmVuIHRvIHRoZSBJbml0aWF0b3IuCgogICAgICBvICBUaGUgYW1vdW50IG9mIHRp bWUgdGhlIEluaXRpYXRvciBzcGVudCB0byBzb2x2ZSB0aGUgcHV6emxlcy4gCiAgICAgIFRo aXMgY2FuIGJlIGNhbGN1bGF0ZWQgaWYgdGhlIGNvb2tpZSBpcyB0aW1lc3RhbXBlZC4KCiAg IFRoaXMgaW5mb3JtYXRpb24gaGVscHMgdGhlIFJlc3BvbmRlciB0byBtYWtlIGEgZGVjaXNp b24gd2hldGhlciB0bwogICBzZXJ2ZSB0aGlzIHJlcXVlc3Qgb3IgZGVtYW5kIG1vcmUgd29y ayBmcm9tIHRoZSBJbml0aWF0b3IuCgogICBPbmUgcG9zc2libGUgYXBwcm9hY2ggdG8gZ2V0 IHRoaXMgaW5mb3JtYXRpb24gaXMgdG8gZW5jb2RlIGl0IGluIHRoZQogICBjb29raWUuICBU aGUgZm9ybWF0IG9mIHN1Y2ggZW5jb2RpbmcgaXMgYSBsb2NhbCBtYXR0ZXIgb2YgUmVzcG9u ZGVyLAogICBhcyB0aGUgY29va2llIHdvdWxkIHJlbWFpbiBhbiBvcGFxdWUgYmxvYiB0byB0 aGUgSW5pdGlhdG9yLiAgSWYgdGhpcwogICBpbmZvcm1hdGlvbiBpcyBlbmNvZGVkIGluIHRo ZSBjb29raWUsIHRoZW4gdGhlIFJlc3BvbmRlciBNVVNUIG1ha2UgaXQKICAgaW50ZWdyaXR5 IHByb3RlY3RlZCwgc28gdGhhdCBhbnkgaW50ZW5kZWQgb3IgYWNjaWRlbnRhbCBhbHRlcmF0 aW9uIG9mCiAgIHRoaXMgaW5mb3JtYXRpb24gaW4gcmV0dXJuZWQgY29va2llIGlzIGRldGVj dGFibGUuICBTbywgdGhlIGNvb2tpZQogICB3b3VsZCBiZSBnZW5lcmF0ZWQgYXM6CgogICBD b29raWUgPSA8VmVyc2lvbklEb2ZTZWNyZXQ+IHwgPEFkZGl0aW9uYWxJbmZvPiB8CiAgICAg ICAgICAgICAgICAgICAgIEhhc2goTmkgfCBJUGkgfCBTUElpIHwgPEFkZGl0aW9uYWxJbmZv PiB8IDxzZWNyZXQ+KQoKICAgQWx0ZXJuYXRpdmVseSwgdGhlIFJlc3BvbmRlciBtYXkgY29u dGludWUgdG8gZ2VuZXJhdGUgY29va2llIGFzCiAgIHN1Z2dlc3RlZCBpbiBTZWN0aW9uIDIu NiBvZiBbUkZDNzI5Nl0sIGJ1dCBhc3NvY2lhdGUgdGhlIGFkZGl0aW9uYWwKICAgaW5mb3Jt YXRpb24sIHRoYXQgd291bGQgYmUgc3RvcmVkIGxvY2FsbHksIHdpdGggdGhlIHBhcnRpY3Vs YXIKICAgdmVyc2lvbiBvZiB0aGUgc2VjcmV0LiAgSW4gdGhpcyBjYXNlIHRoZSBSZXNwb25k ZXIgc2hvdWxkIGhhdmUKICAgZGlmZmVyZW50IHNlY3JldHMgZm9yIGV2ZXJ5IGNvbWJpbmF0 aW9uIG9mIGRpZmZpY3VsdHkgbGV2ZWwgYW5kCiAgIG51bWJlciBvZiBjb25zZWN1dGl2ZSBw dXp6bGVzLCBhbmQgc2hvdWxkIGNoYW5nZSB0aGUgc2VjcmV0cwogICBwZXJpb2RpY2FsbHks IGtlZXBpbmcgYSBmZXcgcHJldmlvdXMgdmVyc2lvbnMsIHRvIGJlIGFibGUgdG8KICAgY2Fs Y3VsYXRlIGhvdyBsb25nIGFnbyB0aGUgY29va2llIHdhcyBnZW5lcmF0ZWQuCgogICBUaGUg UmVzcG9uZGVyIG1heSBhbHNvIGNvbWJpbmUgdGhlc2UgYXBwcm9hY2hlcy4gIFRoaXMgZG9j dW1lbnQKICAgZG9lc24ndCBtYW5kYXRlIGhvdyB0aGUgUmVzcG9uZGVyIGxlYXJucyB0aGlz IGluZm9ybWF0aW9uIGZyb20gdGhlCiAgIGNvb2tpZS4KCiAgICAgICAgNy4xLjIuICBTb2x2 aW5nIFB1enpsZSBhbmQgUmV0dXJuaW5nIHRoZSBTb2x1dGlvbgoKICAgSWYgdGhlIEluaXRp YXRvciByZWNlaXZlcyBhIHB1enpsZSBidXQgaXQgZG9lc24ndCBzdXBwb3J0IHB1enpsZXMs CiAgIHRoZW4gaXQgd2lsbCBpZ25vcmUgdGhlIFBVWlpMRSBub3RpZmljYXRpb24gYXMgYW4g dW5yZWNvZ25pemVkIHN0YXR1cwogICBub3RpZmljYXRpb24gKGluIGFjY29yZGFuY2UgdG8g U2VjdGlvbiAzLjEwLjEgb2YgW1JGQzcyOTZdKS4gIFRoZQogICBJbml0aWF0b3IgYWxzbyBN QVkgaWdub3JlIHRoZSBQVVpaTEUgbm90aWZpY2F0aW9uIGlmIGl0IGlzIG5vdAogICB3aWxs aW5nIHRvIHNwZW5kIHJlc291cmNlcyB0byBzb2x2ZSB0aGUgcHV6emxlIG9mIHRoZSByZXF1 ZXN0ZWQKICAgZGlmZmljdWx0eSwgZXZlbiBpZiBpdCBzdXBwb3J0cyBwdXp6bGVzLiAgSW4g Ym90aCBjYXNlcyB0aGUgSW5pdGlhdG9yCiAgIGFjdHMgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMi42IG9mIFtSRkM3Mjk2XSAtIGl0IHJlc3RhcnRzIHRoZQogICByZXF1ZXN0IGFuZCBp bmNsdWRlcyB0aGUgcmVjZWl2ZWQgQ09PS0lFIG5vdGlmaWNhdGlvbiBpbnRvIGl0LiAgVGhl CiAgIFJlc3BvbmRlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaCB0aGUgc2l0dWF0 aW9uIHdoZW4gaXQganVzdAogICByZXF1ZXN0ZWQgYSBjb29raWUgZnJvbSB0aGUgc2l0dWF0 aW9uIHdoZW4gdGhlIHB1enpsZSB3YXMgZ2l2ZW4gdG8KICAgdGhlIEluaXRpYXRvciwgYnV0 IHRoZSBJbml0aWF0b3IgZm9yIHNvbWUgcmVhc29uIGlnbm9yZWQgaXQuCgogICBJZiB0aGUg cmVjZWl2ZWQgbWVzc2FnZSBjb250YWlucyBhIFBVWlpMRSBub3RpZmljYXRpb24gYW5kIGRv ZXNuJ3QKICAgY29udGFpbiBhIENPT0tJRSBub3RpZmljYXRpb24sIHRoZW4gdGhpcyBtZXNz YWdlIGlzIG1hbGZvcm1lZCBiZWNhdXNlCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRF eHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAg ICAgIE1hcmNoIDIwMTYKCgogICBpdCByZXF1ZXN0cyB0byBzb2x2ZSB0aGUgcHV6emxlLCBi dXQgZG9lc24ndCBwcm92aWRlIGVub3VnaAogICBpbmZvcm1hdGlvbiB0byBkbyBpdC4gIElu IHRoaXMgY2FzZSB0aGUgSW5pdGlhdG9yIFNIT1VMRCByZXNlbmQKICAgSUtFX1NBX0lOSVQg cmVxdWVzdC4gIElmIHRoaXMgc2l0dWF0aW9uIHJlcGVhdHMgc2V2ZXJhbCB0aW1lcywgdGhl bgogICBpdCBtZWFucyB0aGF0IHNvbWV0aGluZyBpcyB3cm9uZyBhbmQgdGhlIElLRSBTQSBj YW5ub3QgYmUKICAgZXN0YWJsaXNoZWQuCgogICBJZiB0aGUgSW5pdGlhdG9yIHN1cHBvcnRz IHB1enpsZXMgYW5kIGlzIHJlYWR5IHRvIGRlYWwgd2l0aCB0aGVtLAogICB0aGVuIGl0IHRy aWVzIHRvIHNvbHZlIHRoZSBnaXZlbiBwdXp6bGUuICBBZnRlciB0aGUgcHV6emxlIGlzIHNv bHZlZAogICB0aGUgSW5pdGlhdG9yIHJlc3RhcnRzIHRoZSByZXF1ZXN0IGFuZCByZXR1cm5z IHRoZSBwdXp6bGUgc29sdXRpb24gaW4KICAgYSBuZXcgcGF5bG9hZCBjYWxsZWQgYSBQdXp6 bGUgU29sdXRpb24gcGF5bG9hZCAoZGVub3RlZCBhcyBQUywgc2VlCiAgIFNlY3Rpb24gOS4y KSBhbG9uZyB3aXRoIHRoZSByZWNlaXZlZCBDT09LSUUgbm90aWZpY2F0aW9uIGJhY2sgdG8g dGhlCiAgIFJlc3BvbmRlci4KCiAgIEhEUiwgTihDT09LSUUpLCBbUFMsXSBTQSwgS0UsIE5p LCBbVitdW04rXSAgIC0tPgoKICAgICAgICA3LjEuMy4gIENvbXB1dGluZyBQdXp6bGUKCiAg IEdlbmVyYWwgcHJpbmNpcGFscyBvZiBjb25zdHJ1Y3RpbmcgcHV6emxlcyBpbiBJS0V2MiBh cmUgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMy4gIFRoZXkgY2FuIGJlIHN1bW1hcml6ZWQg YXMgZm9sbG93czogZ2l2ZW4gdW5wcmVkaWN0YWJsZQogICBzdHJpbmcgUyBhbmQgcHNldWRv LXJhbmRvbSBmdW5jdGlvbiBQUkYgZmluZCBOIGRpZmZlcmVudCBrZXlzIEtpCiAgICh3aGVy ZSBpPVsxLi5OXSkgZm9yIHRoYXQgUFJGIHNvIHRoYXQgdGhlIHJlc3VsdCBvZiBQUkYoS2ks UykgaGFzIGF0CiAgIGxlYXN0IHRoZSBzcGVjaWZpZWQgbnVtYmVyIG9mIHRyYWlsaW5nIHpl cm8gYml0cy4gIFRoaXMgc3BlY2lmaWNhdGlvbgogICByZXF1aXJlcyB0aGF0IHRoZSBzb2x1 dGlvbiB0byB0aGUgcHV6emxlIGNvbnRhaW5zIDQgZGlmZmVyZW50IGtleXMKICAgKGkuZS4g IE49NCkuCgogICBJbiB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UgaXQgaXMgdGhlIGNvb2tp ZSB0aGF0IHBsYXlzIHRoZSByb2xlIG9mCiAgIHVucHJlZGljdGFibGUgc3RyaW5nIFMuICBJ biBvdGhlciB3b3JkcywgaW4gSUtFX1NBX0lOSVQgdGhlIHRhc2sgZm9yCiAgIHRoZSBJS0Ug SW5pdGlhdG9yIGlzIHRvIGZpbmQgdGhlIGZvdXIgZGlmZmVyZW50LCBlcXVhbC1zaXplZCBr ZXlzIEtpCiAgIGZvciB0aGUgYWdyZWVkIHVwb24gUFJGIHN1Y2ggdGhhdCBlYWNoIHJlc3Vs dCBvZiBQUkYoS2ksY29va2llKSB3aGVyZQogICBpID0gWzEuLjRdIGhhcyBhIHN1ZmZpY2ll bnQgbnVtYmVyIG9mIHRyYWlsaW5nIHplcm8gYml0cy4gIE9ubHkgdGhlCiAgIGNvbnRlbnQg b2YgdGhlIENPT0tJRSBub3RpZmljYXRpb24gaXMgdXNlZCBpbiBwdXp6bGUgY2FsY3VsYXRp b24sCiAgIGkuZS4gdGhlIGhlYWRlciBvZiB0aGUgTm90aWZpY2F0aW9uIHBheWxvYWQgaXMg bm90IGluY2x1ZGVkLgoKICAgTm90ZSwgdGhhdCBwdXp6bGVzIGluIHRoZSBJS0VfQVVUSCBl eGNoYW5nZSBhcmUgY29tcHV0ZWQgZGlmZmVyZW50bHkKICAgdGhhbiBpbiB0aGUgSUtFX1NB X0lOSVRfRVhDSEFOR0UuICBTZWUgU2VjdGlvbiA3LjIuMyBmb3IgZGV0YWlscy4KCiAgICAg ICAgNy4xLjQuICBBbmFseXppbmcgUmVwZWF0ZWQgUmVxdWVzdAoKICAgVGhlIHJlY2VpdmVk IHJlcXVlc3QgbXVzdCBhdCBsZWFzdCBjb250YWluIGEgQ09PS0lFIG5vdGlmaWNhdGlvbi4K ICAgT3RoZXJ3aXNlIGl0IGlzIGFuIGluaXRpYWwgcmVxdWVzdCBhbmQgaXQgbXVzdCBiZSBw cm9jZXNzZWQgYWNjb3JkaW5nCiAgIHRvIFNlY3Rpb24gNy4xLiAgRmlyc3QsIHRoZSBjb29r aWUgTVVTVCBiZSBjaGVja2VkIGZvciB2YWxpZGl0eS4gIElmCiAgIHRoZSBjb29raWUgaXMg aW52YWxpZCwgdGhlbiB0aGUgcmVxdWVzdCBpcyB0cmVhdGVkIGFzIGluaXRpYWwgYW5kIGlz CiAgIHByb2Nlc3NlZCBhY2NvcmRpbmcgdG8gU2VjdGlvbiA3LjEuICBJdCBpcyBSRUNPTU1F TkRFRCB0aGF0IGEgbmV3CiAgIGNvb2tpZSBpcyByZXF1ZXN0ZWQgaW4gdGhpcyBjYXNlLgoK ICAgSWYgdGhlIGNvb2tpZSBpcyB2YWxpZCB0aGVuIHNvbWUgaW1wb3J0YW50IGluZm9ybWF0 aW9uIGlzIGxlYXJuZWQKICAgZnJvbSBpdCBvciBmcm9tIGxvY2FsIHN0YXRlIGJhc2VkIG9u IGlkZW50aWZpZXIgb2YgdGhlIGNvb2tpZSdzCiAgIHNlY3JldCAoc2VlIFNlY3Rpb24gNy4x LjEuMyBmb3IgZGV0YWlscykuICBUaGlzIGluZm9ybWF0aW9uIGhlbHBzIHRoZQogCgoKTmly ICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAg ICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rp b24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgUmVzcG9uZGVyIHRv IHNvcnQgb3V0IGluY29taW5nIHJlcXVlc3RzLCBnaXZpbmcgbW9yZSBwcmlvcml0eSB0bwog ICB0aG9zZSBvZiB0aGVtLCB3aGljaCB3ZXJlIGNyZWF0ZWQgYnkgc3BlbmRpbmcgbW9yZSBv ZiB0aGUgSW5pdGlhdG9yJ3MKICAgcmVzb3VyY2VzLgoKICAgRmlyc3QsIHRoZSBSZXNwb25k ZXIgZGV0ZXJtaW5lcyBpZiBpdCByZXF1ZXN0ZWQgb25seSBhIGNvb2tpZSwgb3IKICAgcHJl c2VudGVkIGEgcHV6emxlIHRvIHRoZSBJbml0aWF0b3IuICBJZiBubyBwdXp6bGUgd2FzIGdp dmVuLCB0aGVuIGl0CiAgIG1lYW5zIHRoYXQgYXQgdGhlIHRpbWUgdGhlIFJlc3BvbmRlciBy ZXF1ZXN0ZWQgYSBjb29raWUgaXQgZGlkbid0CiAgIGRldGVjdCB0aGUgKEQpRG9TIGF0dGFj ayBvciB0aGUgYXR0YWNrIHZvbHVtZSB3YXMgbG93LiAgSW4gdGhpcyBjYXNlCiAgIHRoZSBy ZWNlaXZlZCByZXF1ZXN0IG1lc3NhZ2UgbXVzdCBub3QgY29udGFpbiB0aGUgUFMgcGF5bG9h ZCwgYW5kCiAgIHRoaXMgcGF5bG9hZCBNVVNUIGJlIGlnbm9yZWQgaWYgZm9yIGFueSByZWFz b24gdGhlIG1lc3NhZ2UgY29udGFpbnMKICAgaXQuICBTaW5jZSBubyBwdXp6bGUgd2FzIGdp dmVuLCB0aGUgUmVzcG9uZGVyIG1hcmtzIHRoZSByZXF1ZXN0IHdpdGgKICAgdGhlIGxvd2Vz dCBwcmlvcml0eSBzaW5jZSB0aGUgSW5pdGlhdG9yIHNwZW50IGxpdHRsZSByZXNvdXJjZXMK ICAgY3JlYXRpbmcgaXQuCgogICBJZiB0aGUgUmVzcG9uZGVyIGxlYXJucyBmcm9tIHRoZSBj b29raWUgdGhhdCB0aGUgcHV6emxlIHdhcyBnaXZlbiB0bwogICB0aGUgSW5pdGlhdG9yLCB0 aGVuIGl0IGxvb2tzIGZvciB0aGUgUFMgcGF5bG9hZCB0byBkZXRlcm1pbmUgd2hldGhlcgog ICBpdHMgcmVxdWVzdCB0byBzb2x2ZSB0aGUgcHV6emxlIHdhcyBob25vcmVkIG9yIG5vdC4g IElmIHRoZSBpbmNvbWluZwogICBtZXNzYWdlIGRvZXNuJ3QgY29udGFpbiBhIFBTIHBheWxv YWQsIHRoZW4gaXQgbWVhbnMgdGhhdCB0aGUKICAgSW5pdGlhdG9yIGVpdGhlciBkb2Vzbid0 IHN1cHBvcnQgcHV6emxlcyBvciBkb2Vzbid0IHdhbnQgdG8gZGVhbCB3aXRoCiAgIHRoZW0u ICBJbiBlaXRoZXIgY2FzZSB0aGUgcmVxdWVzdCBpcyBtYXJrZWQgd2l0aCB0aGUgbG93ZXN0 IHByaW9yaXR5CiAgIHNpbmNlIHRoZSBJbml0aWF0b3Igc3BlbnQgbGl0dGxlIHJlc291cmNl cyBjcmVhdGluZyBpdC4KCiAgIElmIGEgUFMgcGF5bG9hZCBpcyBmb3VuZCBpbiB0aGUgbWVz c2FnZSwgdGhlbiB0aGUgUmVzcG9uZGVyIE1VU1QKICAgdmVyaWZ5IHRoZSBwdXp6bGUgc29s dXRpb24gdGhhdCBpdCBjb250YWlucy4gIFRoZSBzb2x1dGlvbiBpcwogICBpbnRlcnByZXRl ZCBhcyBmb3VyIGRpZmZlcmVudCBrZXlzLiAgVGhlIHJlc3VsdCBvZiB1c2luZyBlYWNoIG9m IHRoZW0KICAgaW4gdGhlIFBSRiAoYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4xLjMpIG11 c3QgY29udGFpbiBhdCBsZWFzdCB0aGUKICAgcmVxdWVzdGVkIG51bWJlciBvZiB0cmFpbGlu ZyB6ZXJvIGJpdHMuICBUaGUgUmVzcG9uZGVyIE1VU1QgY2hlY2sgYWxsCiAgIHRoZSBmb3Vy IHJldHVybmVkIGtleXMuCgogICBJZiBhbnkgY2hlY2tlZCByZXN1bHQgY29udGFpbnMgZmV3 ZXIgYml0cyB0aGFuIHdlcmUgcmVxdWVzdGVkLCBpdAogICBtZWFucyB0aGF0IHRoZSBJbml0 aWF0b3Igc3BlbnQgbGVzcyByZXNvdXJjZXMgdGhhbiBleHBlY3RlZCBieSB0aGUKICAgUmVz cG9uZGVyLiAgVGhpcyByZXF1ZXN0IGlzIG1hcmtlZCB3aXRoIHRoZSBsb3dlc3QgcHJpb3Jp dHkuCgogICBJZiB0aGUgSW5pdGlhdG9yIHByb3ZpZGVkIHRoZSBzb2x1dGlvbiB0byB0aGUg cHV6emxlIHNhdGlzZnlpbmcgdGhlCiAgIHJlcXVlc3RlZCBkaWZmaWN1bHR5IGxldmVsLCBv ciBpZiB0aGUgUmVzcG9uZGVyIGRpZG4ndCBpbmRpY2F0ZSBhbnkKICAgcGFydGljdWxhciBk aWZmaWN1bHR5IGxldmVsIChieSBzZXR0aW5nIFpCQyB0byB6ZXJvKSBhbmQgdGhlCiAgIElu aXRpYXRvciB3YXMgZnJlZSB0byBzZWxlY3QgYW55IGRpZmZpY3VsdHkgbGV2ZWwgaXQgY2Fu IGFmZm9yZCwgdGhlbgogICB0aGUgcHJpb3JpdHkgb2YgdGhlIHJlcXVlc3QgaXMgY2FsY3Vs YXRlZCBiYXNlZCBvbiB0aGUgZm9sbG93aW5nCiAgIGNvbnNpZGVyYXRpb25zOgoKICAgICAg byAgVGhlIFJlc3BvbmRlciBtdXN0IHRha2UgdGhlIHNtYWxsZXN0IG51bWJlciBvZiB0cmFp bGluZyB6ZXJvCiAgICAgIGJpdHMgYW1vbmcgdGhlIGNoZWNrZWQgcmVzdWx0cyBhbmQgY291 bnQgaXQgYXMgdGhlIG51bWJlciBvZiB6ZXJvCiAgICAgIGJpdHMgdGhlIEluaXRpYXRvciBn b3QuCgogICAgICBvICBUaGUgaGlnaGVyIG51bWJlciBvZiB6ZXJvIGJpdHMgdGhlIEluaXRp YXRvciBnb3QsIHRoZSBoaWdoZXIKICAgICAgcHJpb3JpdHkgaXRzIHJlcXVlc3Qgc2hvdWxk IHJlY2VpdmUuCgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVt YmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAx NgoKCiAgIG8gIFRoZSBtb3JlIGNvbnNlY3V0aXZlIHB1enpsZXMgdGhlIEluaXRpYXRvciBz b2x2ZWQsIHRoZSBoaWdoZXIKICAgICAgcHJpb3JpdHkgaXQgc2hvdWxkIHJlY2VpdmUuCgog ICAgICBvICBUaGUgbW9yZSB0aW1lIHRoZSBJbml0aWF0b3Igc3BlbnQgc29sdmluZyB0aGUg cHV6emxlcywgdGhlCiAgICAgIGhpZ2hlciBwcmlvcml0eSBpdCBzaG91bGQgcmVjZWl2ZS4K CiAgIEFmdGVyIHRoZSBwcmlvcml0eSBvZiB0aGUgcmVxdWVzdCBpcyBkZXRlcm1pbmVkIHRo ZSBmaW5hbCBkZWNpc2lvbgogICB3aGV0aGVyIHRvIHNlcnZlIGl0IG9yIG5vdCBpcyBtYWRl LgoKICAgICAgICA3LjEuNS4gIE1ha2luZyBEZWNpc2lvbiB3aGV0aGVyIHRvIFNlcnZlIHRo ZSBSZXF1ZXN0CgogICBUaGUgUmVzcG9uZGVyIGRlY2lkZXMgd2hhdCB0byBkbyB3aXRoIHRo ZSByZXF1ZXN0IGJhc2VkIG9uIGl0cwogICBwcmlvcml0eSBhbmQgUmVzcG9uZGVyJ3MgY3Vy cmVudCBsb2FkLiAgVGhlcmUgYXJlIHRocmVlIHBvc3NpYmxlCiAgIGFjdGlvbnM6CgogICAg ICBvICBBY2NlcHQgcmVxdWVzdC4KCiAgICAgIG8gIFJlamVjdCByZXF1ZXN0LgoKICAgICAg byAgRGVtYW5kIG1vcmUgd29yayBmcm9tIEluaXRpYXRvciBieSBnaXZpbmcgaXQgYSBuZXcg cHV6emxlLgoKICAgVGhlIFJlc3BvbmRlciBTSE9VTEQgYWNjZXB0IGFuIGluY29taW5nIHJl cXVlc3QgaWYgaXRzIHByaW9yaXR5IGlzCiAgIGhpZ2ggLSBpdCBtZWFucyB0aGF0IHRoZSBJ bml0aWF0b3Igc3BlbnQgcXVpdGUgYSBsb3Qgb2YgcmVzb3VyY2VzLgogICBUaGUgUmVzcG9u ZGVyIE1BWSBhbHNvIGFjY2VwdCBzb21lIG9mIGxvdy1wcmlvcml0eSByZXF1ZXN0cyB3aGVy ZSB0aGUKICAgSW5pdGlhdG9ycyBkb24ndCBzdXBwb3J0IHB1enpsZXMuICBUaGUgcGVyY2Vu dGFnZSBvZiBhY2NlcHRlZCBsZWdhY3kKICAgcmVxdWVzdHMgZGVwZW5kcyBvbiB0aGUgUmVz cG9uZGVyJ3MgY3VycmVudCBsb2FkLgoKICAgSWYgdGhlIEluaXRpYXRvciBzb2x2ZWQgdGhl IHB1enpsZSwgYnV0IGRpZG4ndCBzcGVuZCBtdWNoIHJlc291cmNlcwogICBmb3IgaXQgKHRo ZSBzZWxlY3RlZCBwdXp6bGUgZGlmZmljdWx0eSBsZXZlbCBhcHBlYXJlZCB0byBiZSBsb3cg YW5kCiAgIHRoZSBJbml0aWF0b3Igc29sdmVkIGl0IHF1aWNrbHkpLCB0aGVuIHRoZSBSZXNw b25kZXIgU0hPVUxEIGdpdmUgaXQKICAgYW5vdGhlciBwdXp6bGUuICBUaGUgbW9yZSBwdXp6 bGVzIHRoZSBJbml0aWF0b3Igc29sdmVzIHRoZSBoaWdoZXIgaXRzCiAgIGNoYW5jZXMgYXJl IHRvIGJlIHNlcnZlZC4KCiAgIFRoZSBkZXRhaWxzIG9mIGhvdyB0aGUgUmVzcG9uZGVyIG1h a2VzIGEgZGVjaXNpb24gZm9yIGFueSBwYXJ0aWN1bGFyCiAgIHJlcXVlc3QsIGFyZSBpbXBs ZW1lbnRhdGlvbiBkZXBlbmRlbnQuICBUaGUgUmVzcG9uZGVyIGNhbiBjb2xsZWN0IGFsbAog ICB0aGUgaW5jb21pbmcgcmVxdWVzdHMgZm9yIHNvbWUgc2hvcnQgcGVyaW9kIG9mIHRpbWUs IHNvcnQgdGhlbSBvdXQKICAgYmFzZWQgb24gdGhlaXIgcHJpb3JpdHksIGNhbGN1bGF0ZSB0 aGUgbnVtYmVyIG9mIGF2YWlsYWJsZSBtZW1vcnkKICAgc2xvdHMgZm9yIGhhbGYtb3BlbiBJ S0UgU0FzIGFuZCB0aGVuIHNlcnZlIHRoYXQgbnVtYmVyIG9mIHJlcXVlc3RzCiAgIGZyb20g dGhlIGhlYWQgb2YgdGhlIHNvcnRlZCBsaXN0LiAgVGhlIHJlc3Qgb2YgcmVxdWVzdHMgY2Fu IGJlIGVpdGhlcgogICBkaXNjYXJkZWQgb3IgcmVzcG9uZGVkIHRvIHdpdGggbmV3IHB1enps ZXMuCgogICBBbHRlcm5hdGl2ZWx5LCB0aGUgUmVzcG9uZGVyIG1heSBkZWNpZGUgd2hldGhl ciB0byBhY2NlcHQgZXZlcnkKICAgaW5jb21pbmcgcmVxdWVzdCB3aXRoIHNvbWUga2luZCBv ZiBsb3R0ZXJ5LCB0YWtpbmcgaW50byBhY2NvdW50IGl0cwogICBwcmlvcml0eSBhbmQgdGhl IGF2YWlsYWJsZSByZXNvdXJjZXMuCgoKCgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0 RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAg ICAgICBNYXJjaCAyMDE2CgoKNy4yLiAgUHV6emxlcyBpbiBJS0VfQVVUSCBFeGNoYW5nZQoK ICAgT25jZSB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UgaXMgY29tcGxldGVkLCB0aGUgUmVz cG9uZGVyIGhhcyBjcmVhdGVkCiAgIGEgc3RhdGUgYW5kIGlzIHdhaXRpbmcgZm9yIHRoZSBm aXJzdCBtZXNzYWdlIG9mIHRoZSBJS0VfQVVUSCBleGNoYW5nZQogICBmcm9tIHRoZSBJbml0 aWF0b3IuICBBdCB0aGlzIHBvaW50IHRoZSBJbml0aWF0b3IgaGFzIGFscmVhZHkgcGFzc2Vk CiAgIHJldHVybiByb3V0YWJpbGl0eSBjaGVjayBhbmQgaGFzIHByb3ZlZCB0aGF0IGl0IGhh cyBwZXJmb3JtZWQgc29tZQogICB3b3JrIHRvIGNvbXBsZXRlIElLRV9TQV9JTklUIGV4Y2hh bmdlLiAgSG93ZXZlciwgdGhlIEluaXRpYXRvciBpcyBub3QKICAgeWV0IGF1dGhlbnRpY2F0 ZWQgYW5kIHRoaXMgZmFjdCBhbGxvd3MgbWFsaWNpb3VzIEluaXRpYXRvciB0byBwZXJmb3Jt CiAgIGFuIGF0dGFjaywgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4gIFVubGlrZSBEb1MgYXR0 YWNrIGluIElLRV9TQV9JTklUCiAgIGV4Y2hhbmdlLCB3aGljaCBpcyB0YXJnZXRlZCBvbiB0 aGUgUmVzcG9uZGVyJ3MgbWVtb3J5IHJlc291cmNlcywgdGhlCiAgIGdvYWwgb2YgdGhpcyBh dHRhY2sgaXMgdG8gZXhoYXVzdCBhIFJlc3BvbmRlcidzIENQVSBwb3dlci4gIFRoZQogICBh dHRhY2sgaXMgcGVyZm9ybWVkIGJ5IHNlbmRpbmcgdGhlIGZpcnN0IElLRV9BVVRIIG1lc3Nh Z2UgY29udGFpbmluZwogICBnYXJiYWdlLiAgVGhpcyBjb3N0cyBub3RoaW5nIHRvIHRoZSBJ bml0aWF0b3IsIGJ1dCB0aGUgUmVzcG9uZGVyIGhhcwogICB0byBkbyByZWxhdGl2ZWx5IGNv c3RseSBvcGVyYXRpb25zIG9mIGNvbXB1dGluZyB0aGUgRC1IIHNoYXJlZCBzZWNyZXQKICAg YW5kIGRlcml2aW5nIFNLXyoga2V5cyB0byBiZSBhYmxlIHRvIHZlcmlmeSBhdXRoZW50aWNp dHkgb2YgdGhlCiAgIG1lc3NhZ2UuICBJZiB0aGUgUmVzcG9uZGVyIGRvZXNuJ3Qga2VlcCB0 aGUgY29tcHV0ZWQga2V5cyBhZnRlciBhbgogICB1bnN1Y2Nlc3NmdWwgdmVyaWZpY2F0aW9u IG9mIHRoZSBJS0VfQVVUSCBtZXNzYWdlLCB0aGVuIHRoZSBhdHRhY2sKICAgY2FuIGJlIHJl cGVhdGVkIHNldmVyYWwgdGltZXMgb24gdGhlIHNhbWUgSUtFIFNBLgoKICAgVGhlIFJlc3Bv bmRlciBjYW4gdXNlIHB1enpsZXMgdG8gbWFrZSB0aGlzIGF0dGFjayBtb3JlIGNvc3RseSBm b3IgdGhlCiAgIEluaXRpYXRvci4gIFRoZSBpZGVhIGlzIHRoYXQgdGhlIFJlc3BvbmRlciBp bmNsdWRlcyBhIHB1enpsZSBpbiB0aGUKICAgSUtFX1NBX0lOSVQgcmVzcG9uc2UgbWVzc2Fn ZSBhbmQgdGhlIEluaXRpYXRvciBpbmNsdWRlcyBhIHB1enpsZQogICBzb2x1dGlvbiBpbiB0 aGUgZmlyc3QgSUtFX0FVVEggcmVxdWVzdCBtZXNzYWdlIG91dHNpZGUgdGhlIEVuY3J5cHRl ZAogICBwYXlsb2FkLCBzbyB0aGF0IHRoZSBSZXNwb25kZXIgaXMgYWJsZSB0byB2ZXJpZnkg cHV6emxlIHNvbHV0aW9uCiAgIGJlZm9yZSBjb21wdXRpbmcgRC1IIHNoYXJlZCBzZWNyZXQu ICBUaGUgZGlmZmljdWx0eSBsZXZlbCBvZiB0aGUKICAgcHV6emxlIHNob3VsZCBiZSBzZWxl Y3RlZCBzbyB0aGF0IHRoZSBJbml0aWF0b3Igd291bGQgc3BlbmQKICAgc3Vic3RhbnRpYWxs eSBtb3JlIHRpbWUgdG8gc29sdmUgdGhlIHB1enpsZSB0aGFuIHRoZSBSZXNwb25kZXIgdG8K ICAgY29tcHV0ZSB0aGUgc2hhcmVkIHNlY3JldC4KCiAgIFRoZSBSZXNwb25kZXIgc2hvdWxk IGNvbnN0YW50bHkgbW9uaXRvciB0aGUgYW1vdW50IG9mIHRoZSBoYWxmLW9wZW4KICAgSUtF IFNBIHN0YXRlcyB0aGF0IHJlY2VpdmUgSUtFX0FVVEggbWVzc2FnZXMgdGhhdCBjYW5ub3Qg YmUgZGVjcnlwdGVkCiAgIGR1ZSB0byBpbnRlZ3JpdHkgY2hlY2sgZmFpbHVyZXMuICBJZiB0 aGUgcGVyY2VudGFnZSBvZiBzdWNoIHN0YXRlcyBpcwogICBoaWdoIGFuZCBpdCB0YWtlcyBh biBlc3NlbnRpYWwgZnJhY3Rpb24gb2YgUmVzcG9uZGVyJ3MgY29tcHV0aW5nCiAgIHBvd2Vy IHRvIGNhbGN1bGF0ZSBrZXlzIGZvciB0aGVtLCB0aGVuIHRoZSBSZXNwb25kZXIgbWF5IGFz c3VtZSB0aGF0CiAgIGl0IGlzIHVuZGVyIGF0dGFjayBhbmQgU0hPVUxEIHVzZSBwdXp6bGVz IHRvIG1ha2UgaXQgaGFyZGVyIGZvcgogICBhdHRhY2tlcnMuCgogICAgICAgIDcuMi4xLiAg UHJlc2VudGluZyBQdXp6bGUKCiAgIFRoZSBSZXNwb25kZXIgcmVxdWVzdHMgdGhlIEluaXRp YXRvciB0byBzb2x2ZSBhIHB1enpsZSBieSBpbmNsdWRpbmcKICAgdGhlIFBVWlpMRSBub3Rp ZmljYXRpb24gaW4gdGhlIElLRV9TQV9JTklUIHJlc3BvbnNlIG1lc3NhZ2UuICBUaGUKICAg UmVzcG9uZGVyIE1VU1QgTk9UIHVzZSBwdXp6bGVzIGluIHRoZSBJS0VfQVVUSCBleGNoYW5n ZSB1bmxlc3MgdGhlCiAgIHB1enpsZSBoYXMgYmVlbiBwcmV2aW91c2x5IHByZXNlbnRlZCBh bmQgc29sdmVkIGluIHRoZSBwcmVjZWRpbmcKICAgSUtFX1NBX0lOSVQgZXhjaGFuZ2UuCgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSAgIEhEUiwgU0EsIEtFLCBOciwgTihQ VVpaTEUpLCBbVitdW04rXQoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVz IFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1h cmNoIDIwMTYKCgo3LjIuMS4xLiAgU2VsZWN0aW5nIFB1enpsZSBEaWZmaWN1bHR5IExldmVs CgogICBUaGUgZGlmZmljdWx0eSBsZXZlbCBvZiB0aGUgcHV6emxlIGluIElLRV9BVVRIIGV4 Y2hhbmdlIHNob3VsZCBiZQogICBjaG9zZW4gc28gdGhhdCB0aGUgSW5pdGlhdG9yIHdvdWxk IHNwZW5kIG1vcmUgdGltZSB0byBzb2x2ZSB0aGUKICAgcHV6emxlIHRoYW4gdGhlIFJlc3Bv bmRlciB0byBjb21wdXRlIHRoZSBELUggc2hhcmVkIHNlY3JldCBhbmQgdGhlCiAgIGtleXMs IG5lZWRlZCB0byBkZWNyeXB0IGFuZCB2ZXJpZnkgdGhlIElLRV9BVVRIIHJlcXVlc3QgbWVz c2FnZS4gIE9uCiAgIHRoZSBvdGhlciBoYW5kLCB0aGUgZGlmZmljdWx0eSBsZXZlbCBzaG91 bGQgbm90IGJlIHRvbyBoaWdoLAogICBvdGhlcndpc2UgdGhlIGxlZ2l0aW1hdGUgY2xpZW50 cyB3b3VsZCBleHBlcmllbmNlIGFuIGFkZGl0aW9uYWwgZGVsYXkKICAgd2hpbGUgZXN0YWJs aXNoaW5nIElLRSBTQS4KCiAgIE5vdGUsIHRoYXQgc2luY2UgcHV6emxlcyBpbiB0aGUgSUtF X0FVVEggZXhjaGFuZ2UgYXJlIG9ubHkgYWxsb3dlZCB0bwogICBiZSB1c2VkIGlmIHRoZXkg d2VyZSB1c2VkIGluIHRoZSBwcmVjZWRpbmcgSUtFX1NBX0lOSVQgZXhjaGFuZ2UsIHRoZQog ICBSZXNwb25kZXIgd291bGQgYmUgYWJsZSB0byBlc3RpbWF0ZSB0aGUgY29tcHV0YXRpb25h bCBwb3dlciBvZiB0aGUKICAgSW5pdGlhdG9yIGFuZCB0byBzZWxlY3QgdGhlIGRpZmZpY3Vs dHkgbGV2ZWwgYWNjb3JkaW5nbHkuICBVbmxpa2UKICAgcHV6emxlcyBpbiBJS0VfU0FfSU5J VCwgdGhlIHJlcXVlc3RlZCBkaWZmaWN1bHR5IGxldmVsIGZvciBJS0VfQVVUSAogICBwdXp6 bGVzIE1VU1QgTk9UIGJlIHplcm8uICBJbiBvdGhlciB3b3JkcywgdGhlIFJlc3BvbmRlciBt dXN0IGFsd2F5cwogICBzZXQgc3BlY2lmaWMgZGlmZmljdWx0eSBsZXZlbCBhbmQgbXVzdCBu b3QgbGV0IHRoZSBJbml0aWF0b3IgdG8KICAgY2hvb3NlIGl0IG9uIGl0cyBvd24uCgogICAg ICAgICAgNy4yLjEuMi4gIFNlbGVjdGluZyBQdXp6bGUgQWxnb3JpdGhtCgogICBUaGUgYWxn b3JpdGhtIGZvciB0aGUgcHV6emxlIGlzIHNlbGVjdGVkIGFzIGRlc2NyaWJlZCBpbgogICBT ZWN0aW9uIDcuMS4xLjIuICBUaGVyZSBpcyBubyByZXF1aXJlbWVudCwgdGhhdCB0aGUgYWxn b3JpdGhtIGZvciB0aGUKICAgcHV6emxlIGluIHRoZSBJS0VfU0EgSU5JVCBleGNoYW5nZSBi ZSB0aGUgc2FtZSwgYXMgdGhlIGFsZ29yaXRobSBmb3IKICAgdGhlIHB1enpsZSBpbiBJS0Vf QVVUSCBleGNoYW5nZSwgaG93ZXZlciBpdCBpcyBleHBlY3RlZCB0aGF0IGluIG1vc3QKICAg Y2FzZXMgdGhleSB3aWxsIGJlIHRoZSBzYW1lLgoKICAgICAgICA3LjIuMi4gIFNvbHZpbmcg UHV6emxlIGFuZCBSZXR1cm5pbmcgdGhlIFNvbHV0aW9uCgogICBJZiB0aGUgSUtFX1NBX0lO SVQgcmVzcG9uc2UgbWVzc2FnZSBjb250YWlucyB0aGUgUFVaWkxFIG5vdGlmaWNhdGlvbgog ICBhbmQgdGhlIEluaXRpYXRvciBzdXBwb3J0cyBwdXp6bGVzLCBpdCBNVVNUIHNvbHZlIHRo ZSBwdXp6bGUuICBOb3RlLAogICB0aGF0IHB1enpsZSBjb25zdHJ1Y3Rpb24gaW4gdGhlIElL RV9BVVRIIGV4Y2hhbmdlIGRpZmZlcnMgZnJvbSB0aGUKICAgcHV6emxlIGNvbnN0cnVjdGlv biBpbiB0aGUgSUtFX1NBX0lOSVQgZXhjaGFuZ2UgYW5kIGlzIGRlc2NyaWJlZCBpbgogICBT ZWN0aW9uIDcuMi4zLiAgT25jZSB0aGUgcHV6emxlIGlzIHNvbHZlZCB0aGUgSW5pdGlhdG9y IHNlbmRzIHRoZQogICBJS0VfQVVUSCByZXF1ZXN0IG1lc3NhZ2UsIGNvbnRhaW5pbmcgdGhl IFB1enpsZSBTb2x1dGlvbiBwYXlsb2FkLgoKICAgSERSLCBQUywgU0sge0lEaSwgW0NFUlQs XSBbQ0VSVFJFUSxdCiAgICAgICAgICAgICAgIFtJRHIsXSBBVVRILCBTQSwgVFNpLCBUU3J9 ICAgLS0+CgogICBUaGUgUHV6emxlIFNvbHV0aW9uIHBheWxvYWQgTVVTVCBiZSBwbGFjZWQg b3V0c2lkZSB0aGUgRW5jcnlwdGVkCiAgIHBheWxvYWQsIHNvIHRoYXQgdGhlIFJlc3BvbmRl ciB3b3VsZCBiZSBhYmxlIHRvIHZlcmlmeSB0aGUgcHV6emxlCiAgIGJlZm9yZSBjYWxjdWxh dGluZyB0aGUgRC1IIHNoYXJlZCBzZWNyZXQgYW5kIHRoZSBTS18qIGtleXMuCgogICBJZiBJ S0UgRnJhZ21lbnRhdGlvbiBbUkZDNzM4M10gaXMgdXNlZCBpbiBJS0VfQVVUSCBleGNoYW5n ZSwgdGhlbiB0aGUKICAgUFMgcGF5bG9hZCBNVVNUIGJlIHByZXNlbnQgb25seSBpbiB0aGUg Zmlyc3QgSUtFIEZyYWdtZW50IG1lc3NhZ2UsIGluCiAgIGFjY29yZGFuY2Ugd2l0aCB0aGUg U2VjdGlvbiAyLjUuMyBvZiBbUkZDNzM4M10uICBOb3RlLCB0aGF0CiAgIGNhbGN1bGF0aW9u IG9mIHRoZSBwdXp6bGUgaW4gdGhlIElLRV9BVVRIIGV4Y2hhbmdlIGRvZXNuJ3QgZGVwZW5k IG9uCiAgIHRoZSBjb250ZW50IG9mIHRoZSBJS0VfQVVUSCBtZXNzYWdlIChzZWUgU2VjdGlv biA3LjIuMykuICBUaHVzIHRoZQogCgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJl cyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBN YXJjaCAyMDE2CgoKICAgSW5pdGlhdG9yIGhhcyB0byBzb2x2ZSB0aGUgcHV6emxlIG9ubHkg b25jZSBhbmQgdGhlIHNvbHV0aW9uIGlzIHZhbGlkCiAgIGZvciBib3RoIHVuZnJhZ21lbnRl ZCBhbmQgZnJhZ21lbnRlZCBJS0UgbWVzc2FnZXMuCgogICAgICAgIDcuMi4zLiAgQ29tcHV0 aW5nIFB1enpsZQoKICAgVGhlIHB1enpsZXMgaW4gdGhlIElLRV9BVVRIIGV4Y2hhbmdlIGFy ZSBjb21wdXRlZCBkaWZmZXJlbnRseSB0aGFuIGluCiAgIHRoZSBJS0VfU0FfSU5JVCBleGNo YW5nZSAoc2VlIFNlY3Rpb24gNy4xLjMpLiAgVGhlIGdlbmVyYWwgcHJpbmNpcGxlCiAgIGlz IHRoZSBzYW1lOyB0aGUgZGlmZmVyZW5jZSBpcyBpbiB0aGUgY29uc3RydWN0aW9uIG9mIHRo ZSBzdHJpbmcgUy4KICAgVW5saWtlIHRoZSBJS0VfU0FfSU5JVCBleGNoYW5nZSwgd2hlcmUg UyBpcyB0aGUgY29va2llLCBpbiB0aGUKICAgSUtFX0FVVEggZXhjaGFuZ2UgUyBpcyBhIGNv bmNhdGVuYXRpb24gb2YgTnIgYW5kIFNQSXIuICBJbiBvdGhlcgogICB3b3JkcywgdGhlIHRh c2sgZm9yIElLRSBJbml0aWF0b3IgaXMgdG8gZmluZCB0aGUgZm91ciBkaWZmZXJlbnQga2V5 cwogICBLaSBmb3IgdGhlIGFncmVlZCB1cG9uIFBSRiBzdWNoIHRoYXQgZWFjaCByZXN1bHQg b2YgUFJGKEtpLE5yIHwgU1BJcikKICAgd2hlcmUgaT1bMS4uNF0gaGFzIGEgc3VmZmljaWVu dCBudW1iZXIgb2YgdHJhaWxpbmcgemVybyBiaXRzLiAgTnIgaXMKICAgYSBub25jZSB1c2Vk IGJ5IHRoZSBSZXNwb25kZXIgaW4gSUtFX1NBX0lOSVQgZXhjaGFuZ2UsIHN0cmlwcGVkIG9m CiAgIGFueSBoZWFkZXJzLiAgU1BJciBpcyBJS0UgUmVzcG9uZGVyJ3MgU1BJIGZyb20gdGhl IElLRSBoZWFkZXIgb2YgdGhlCiAgIFNBIGJlaW5nIGVzdGFibGlzaGVkLgoKICAgICAgICA3 LjIuNC4gIFJlY2VpdmluZyBQdXp6bGUgU29sdXRpb24KCiAgIElmIHRoZSBSZXNwb25kZXIg cmVxdWVzdGVkIHRoZSBJbml0aWF0b3IgdG8gc29sdmUgYSBwdXp6bGUgaW4gdGhlCiAgIElL RV9BVVRIIGV4Y2hhbmdlLCB0aGVuIGl0IE1VU1Qgc2lsZW50bHkgZGlzY2FyZCBhbGwgdGhl IElLRV9BVVRICiAgIHJlcXVlc3QgbWVzc2FnZXMgd2l0aG91dCB0aGUgUHV6emxlIFNvbHV0 aW9uIHBheWxvYWQuCgogICBPbmNlIHRoZSBtZXNzYWdlIGNvbnRhaW5pbmcgYSBzb2x1dGlv biB0byB0aGUgcHV6emxlIGlzIHJlY2VpdmVkLCB0aGUKICAgUmVzcG9uZGVyIE1VU1QgdmVy aWZ5IHRoZSBzb2x1dGlvbiBiZWZvcmUgcGVyZm9ybWluZyBjb21wdXRhdGlvbmxseQogICBp bnRlbnNpdmUgb3BlcmF0aW9ucyBpLmUuIGNvbXB1dGluZyB0aGUgRC1IIHNoYXJlZCBzZWNy ZXQgYW5kIHRoZQogICBTS18qIGtleXMuICBUaGUgUmVzcG9uZGVyIE1VU1QgdmVyaWZ5IGFs bCB0aGUgZm91ciByZXR1cm5lZCBrZXlzLgoKICAgVGhlIFJlc3BvbmRlciBNVVNUIHNpbGVu dGx5IGRpc2NhcmQgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgaWYgYW55CiAgIGNoZWNrZWQgdmVy aWZpY2F0aW9uIHJlc3VsdCBpcyBub3QgY29ycmVjdCAoY29udGFpbnMgaW5zdWZmaWNpZW50 CiAgIG51bWJlciBvZiB0cmFpbGluZyB6ZXJvIGJpdHMpLiAgSWYgdGhlIFJlc3BvbmRlciBz dWNjZXNzZnVsbHkKICAgdmVyaWZpZXMgdGhlIHB1enpsZSBhbmQgY2FsY3VsYXRlcyB0aGUg U0tfKiBrZXksIGJ1dCB0aGUgbWVzc2FnZQogICBhdXRoZW50aWNpdHkgY2hlY2sgZmFpbHMs IHRoZW4gaXQgU0hPVUxEIHNhdmUgdGhlIGNhbGN1bGF0ZWQga2V5cyBpbgogICB0aGUgSUtF IFNBIHN0YXRlIHdoaWxlIHdhaXRpbmcgZm9yIHRoZSByZXRyYW5zbWlzc2lvbnMgZnJvbSB0 aGUKICAgSW5pdGlhdG9yLiAgSW4gdGhpcyBjYXNlIHRoZSBSZXNwb25kZXIgbWF5IHNraXAg dmVyaWZpY2F0aW9uIG9mIHRoZQogICBwdXp6bGUgc29sdXRpb24gYW5kIGlnbm9yZSB0aGUg UHV6emxlIFNvbHV0aW9uIHBheWxvYWQgaW4gdGhlCiAgIHJldHJhbnNtaXR0ZWQgbWVzc2Fn ZXMuCgogICBJZiB0aGUgSW5pdGlhdG9yIHVzZXMgSUtFIEZyYWdtZW50YXRpb24sIHRoZW4g aXQgaXMgcG9zc2libGUsIHRoYXQKICAgZHVlIHRvIHBhY2tldCBsb3NzIGFuZC9vciByZW9y ZGVyaW5nIHRoZSBSZXNwb25kZXIgY291bGQgcmVjZWl2ZSBub24tCiAgIGZpcnN0IElLRSBG cmFnbWVudCBtZXNzYWdlcyBiZWZvcmUgcmVjZWl2aW5nIHRoZSBmaXJzdCBvbmUsCiAgIGNv bnRhaW5pbmcgdGhlIFBTIHBheWxvYWQuICBJbiB0aGlzIGNhc2UgdGhlIFJlc3BvbmRlciBN QVkgY2hvb3NlIHRvCiAgIGtlZXAgdGhlIHJlY2VpdmVkIGZyYWdtZW50cyB1bnRpbCB0aGUg Zmlyc3QgZnJhZ21lbnQgY29udGFpbmluZyB0aGUKICAgc29sdXRpb24gdG8gdGhlIHB1enps ZSBpcyByZWNlaXZlZC4gIEhvd2V2ZXIsIGluIHRoaXMgY2FzZSB0aGUKICAgUmVzcG9uZGVy IFNIT1VMRCBOT1QgdHJ5IHRvIHZlcmlmeSBhdXRoZW50aWNpdHkgb2YgdGhlIGtlcHQgZnJh Z21lbnRzCiAgIHVudGlsIHRoZSBmaXJzdCBmcmFnbWVudCB3aXRoIHRoZSBQUyBwYXlsb2Fk IGlzIHJlY2VpdmVkIGFuZCB0aGUKICAgc29sdXRpb24gdG8gdGhlIHB1enpsZSBpcyB2ZXJp ZmllZC4gIEFmdGVyIHN1Y2Nlc3NmdWwgdmVyaWZpY2F0aW9uIG9mCgogCgoKTmlyICYgU215 c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAg W1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9y IElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgdGhlIHB1enpsZSB0aGUgUmVz cG9uZGVyIGNvdWxkIGNhbGN1bGF0ZSB0aGUgU0tfKiBrZXkgYW5kIHZlcmlmeQogICBhdXRo ZW50aWNpdHkgb2YgdGhlIGNvbGxlY3RlZCBmcmFnbWVudHMuCgogICAgOC4gIERvUyBQcm90 ZWN0aW9uIGFmdGVyIElLRSBTQSBpcyBjcmVhdGVkCgogICBPbmNlIElLRSBTQSBpcyBjcmVh dGVkIHRoZXJlIGlzIHVzdWFsbHkgbm90IG11Y2ggdHJhZmZpYyBvdmVyIGl0LiAgSW4KICAg bW9zdCBjYXNlcyB0aGlzIHRyYWZmaWMgY29uc2lzdHMgb2YgZXhjaGFuZ2VzIGFpbWVkIHRv IGNyZWF0ZQogICBhZGRpdGlvbmFsIENoaWxkIFNBcywgcmVrZXksIG9yIGRlbGV0ZSB0aGVt IGFuZCBjaGVjayB0aGUgbGl2ZW5lc3Mgb2YKICAgdGhlIHBlZXIuICBXaXRoIGEgdHlwaWNh bCBzZXR1cCBhbmQgdHlwaWNhbCBDaGlsZCBTQSBsaWZldGltZXMsIHRoZXJlCiAgIGFyZSB0 eXBpY2FsbHkgbm8gbW9yZSB0aGFuIGEgZmV3IHN1Y2ggZXhjaGFuZ2VzLCBvZnRlbiBsZXNz LiAgU29tZSBvZgogICB0aGVzZSBleGNoYW5nZXMgcmVxdWlyZSByZWxhdGl2ZWx5IGxpdHRs ZSByZXNvdXJjZXMgKGxpa2UgbGl2ZW5lc3MKICAgY2hlY2spLCB3aGlsZSBvdGhlcnMgbWF5 IGJlIHJlc291cmNlIGNvbnN1bWluZyAobGlrZSBjcmVhdGluZyBvcgogICByZWtleWluZyBD aGlsZCBTQSB3aXRoIEQtSCBleGNoYW5nZSkuCgogICBTaW5jZSBhbnkgZW5kcG9pbnQgY2Fu IGluaXRpYXRlIGEgbmV3IGV4Y2hhbmdlLCB0aGVyZSBpcyBhCiAgIHBvc3NpYmlsaXR5IHRo YXQgYSBwZWVyIHdvdWxkIGluaXRpYXRlIHRvbyBtYW55IGV4Y2hhbmdlcyB0aGF0IGNvdWxk CiAgIGV4aGF1c3QgaG9zdCByZXNvdXJjZXMuICBGb3IgZXhhbXBsZSwgdGhlIHBlZXIgY2Fu IHBlcmZvcm0gZW5kbGVzcwogICBjb250aW51b3VzIENoaWxkIFNBIHJla2V5aW5nIG9yIGNy ZWF0ZSBvdmVyd2hlbG1pbmcgbnVtYmVyIG9mIENoaWxkCiAgIFNBcyB3aXRoIHRoZSBzYW1l IFRyYWZmaWMgU2VsZWN0b3JzIGV0Yy4gIFN1Y2ggYmVoYXZpb3IgbWF5IGJlIGNhdXNlZAog ICBieSBidWdneSBpbXBsZW1lbnRhdGlvbiwgbWlzY29uZmlndXJhdGlvbiBvciBiZSBpbnRl bnRpb25hbC4gIFRoZQogICBsYXR0ZXIgYmVjb21lcyBtb3JlIG9mIGEgcmVhbCB0aHJlYXQg aWYgdGhlIHBlZXIgdXNlcyBOVUxMCiAgIEF1dGhlbnRpY2F0aW9uLCBkZXNjcmliZWQgaW4g W1JGQzc2MTldLiAgSW4gdGhpcyBjYXNlIHRoZSBwZWVyCiAgIHJlbWFpbnMgYW5vbnltb3Vz LCBhbGxvd2luZyBpdCB0byBlc2NhcGUgYW55IHJlc3BvbnNpYmlsaXR5IGZvciBpdHMKICAg YWN0aW9ucy4KCiAgIFRoZSBmb2xsb3dpbmcgcmVjb21tZW5kYXRpb25zIGZvciBkZWZlbnNl IGFnYWluc3QgcG9zc2libGUgRG9TCiAgIGF0dGFja3MgYWZ0ZXIgSUtFIFNBIGlzIGVzdGFi bGlzaGVkIGFyZSBtb3N0bHkgaW50ZW5kZWQgZm9yCiAgIGltcGxlbWVudGF0aW9ucyB0aGF0 IGFsbG93IHVuYXV0aGVudGljYXRlZCBJS0Ugc2Vzc2lvbnM7IGhvd2V2ZXIsCiAgIHRoZXkg bWF5IGFsc28gYmUgdXNlZnVsIGluIG90aGVyIGNhc2VzLgoKICAgICAgbyAgSWYgdGhlIElL RXYyIHdpbmRvdyBzaXplIGlzIGdyZWF0ZXIgdGhhbiBvbmUsIHRoZW4gdGhlIHBlZXIKICAg ICAgY291bGQgaW5pdGlhdGUgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIGV4Y2hhbmdlcyB0aGF0 IGNvdWxkIGluY3JlYXNlCiAgICAgIGhvc3QgcmVzb3VyY2UgY29uc3VtcHRpb24uICBTaW5j ZSBjdXJyZW50bHkgdGhlcmUgaXMgbm8gd2F5IGluCiAgICAgIElLRXYyIHRvIGRlY3JlYXNl IHdpbmRvdyBzaXplIG9uY2UgaXQgd2FzIGluY3JlYXNlZCAoc2VlCiAgICAgIFNlY3Rpb24g Mi4zIG9mIFtSRkM3Mjk2XSksIHRoZSB3aW5kb3cgc2l6ZSBjYW5ub3QgYmUgZHluYW1pY2Fs bHkKICAgICAgYWRqdXN0ZWQgZGVwZW5kaW5nIG9uIHRoZSBsb2FkLiAgRm9yIHRoYXQgcmVh c29uLCBpdCBpcyBOT1QKICAgICAgUkVDT01NRU5ERUQgdG8gZXZlciBpbmNyZWFzZSB0aGUg SUtFdjIgd2luZG93IHNpemUgYWJvdmUgaXRzCiAgICAgIGRlZmF1bHQgdmFsdWUgb2Ygb25l IGlmIHRoZSBwZWVyIHVzZXMgTlVMTCBBdXRoZW50aWNhdGlvbi4KCiAgICAgIG8gIElmIHRo ZSBwZWVyIGluaXRpYXRlcyByZXF1ZXN0cyB0byByZWtleSBJS0UgU0Egb3IgQ2hpbGQgU0Eg dG9vCiAgICAgIG9mdGVuLCBpbXBsZW1lbnRhdGlvbnMgY2FuIHJlc3BvbmQgdG8gc29tZSBv ZiB0aGVzZSByZXF1ZXN0cyB3aXRoCiAgICAgIHRoZSBURU1QT1JBUllfRkFJTFVSRSBub3Rp ZmljYXRpb24sIGluZGljYXRpbmcgdGhhdCB0aGUgcmVxdWVzdAogICAgICBzaG91bGQgYmUg cmV0cmllZCBhZnRlciBzb21lIHBlcmlvZCBvZiB0aW1lLgoKICAgICAgbyAgSWYgdGhlIHBl ZXIgY3JlYXRlcyB0b28gbWFueSBDaGlsZCBTQSB3aXRoIHRoZSBzYW1lIG9yCiAgICAgIG92 ZXJsYXBwaW5nIFRyYWZmaWMgU2VsZWN0b3JzLCBpbXBsZW1lbnRhdGlvbnMgY2FuIHJlc3Bv bmQgd2l0aAogICAgICB0aGUgTk9fQURESVRJT05BTF9TQVMgbm90aWZpY2F0aW9uLgoKIAoK Ck5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAg ICAgICAgICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90 ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAgTWFyY2ggMjAxNgoKCiAgIG8gIElmIHRo ZSBwZWVyIGluaXRpYXRlcyB0b28gbWFueSBleGNoYW5nZXMgb2YgYW55IGtpbmQsCiAgICAg IGltcGxlbWVudGF0aW9ucyBjYW4gaW50cm9kdWNlIGFuIGFydGlmaWNpYWwgZGVsYXkgYmVm b3JlCiAgICAgIHJlc3BvbmRpbmcgdG8gcmVxdWVzdCBtZXNzYWdlcy4gIFRoaXMgZGVsYXkg d291bGQgZGVjcmVhc2UgdGhlCiAgICAgIHJhdGUgdGhlIGltcGxlbWVudGF0aW9uIG5lZWQg dG8gcHJvY2VzcyByZXF1ZXN0cyBmcm9tIGFueQogICAgICBwYXJ0aWN1bGFyIHBlZXIsIG1h a2luZyBpdCBwb3NzaWJsZSB0byBwcm9jZXNzIHJlcXVlc3RzIGZyb20gdGhlCiAgICAgIG90 aGVycy4gIFRoZSBkZWxheSBzaG91bGQgbm90IGJlIHRvbyBsb25nIHRvIGF2b2lkIGNhdXNp bmcgdGhlIElLRQogICAgICBTQSB0byBiZSBkZWxldGVkIG9uIHRoZSBvdGhlciBlbmQgZHVl IHRvIHRpbWVvdXQuICBJdCBpcyBiZWxpZXZlZAogICAgICB0aGF0IGEgZmV3IHNlY29uZHMg aXMgZW5vdWdoLiAgTm90ZSwgdGhhdCBpZiB0aGUgUmVzcG9uZGVyCiAgICAgIHJlY2VpdmVz IHJldHJhbnNtaXNzaW9ucyBvZiB0aGUgcmVxdWVzdCBtZXNzYWdlIGR1cmluZyB0aGUgZGVs YXkKICAgICAgcGVyaW9kLCB0aGUgcmV0cmFuc21pdHRlZCBtZXNzYWdlcyBzaG91bGQgYmUg c2lsZW50bHkgZGlzY2FyZGVkLgoKICAgICAgbyAgSWYgdGhlc2UgY291bnRlci1tZWFzdXJl cyBhcmUgaW5lZmZpY2llbnQsIGltcGxlbWVudGF0aW9ucyBjYW4KICAgICAgZGVsZXRlIHRo ZSBJS0UgU0Egd2l0aCBhbiBvZmZlbmRpbmcgcGVlciBieSBzZW5kaW5nIERlbGV0ZQogICAg ICBQYXlsb2FkLgoKICAgIDkuICBQYXlsb2FkIEZvcm1hdHMKCiAgICAgIDkuMS4gIFBVWlpM RSBOb3RpZmljYXRpb24KCiAgIFRoZSBQVVpaTEUgbm90aWZpY2F0aW9uIGlzIHVzZWQgYnkg dGhlIElLRSBSZXNwb25kZXIgdG8gaW5mb3JtIHRoZQogICBJbml0aWF0b3IgYWJvdXQgdGhl IG5lY2Vzc2l0eSB0byBzb2x2ZSB0aGUgcHV6emxlLiAgSXQgY29udGFpbnMgdGhlCiAgIGRp ZmZpY3VsdHkgbGV2ZWwgb2YgdGhlIHB1enpsZSBhbmQgdGhlIFBSRiB0aGUgSW5pdGlhdG9y IHNob3VsZCB1c2UuCgogICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHwgTmV4dCBQYXlsb2FkICB8Q3wgIFJFU0VSVkVEICAgfCAgICAgICAgIFBheWxvYWQg TGVuZ3RoICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHxQcm90b2NvbCBJRCg9MCl8IFNQ SSBTaXplICg9MCkgfCAgICAgIE5vdGlmeSBNZXNzYWdlIFR5cGUgICAgICB8CiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICAgICAgICAgICAgIFBSRiAgICAgICAgICAgICAgfCAgRGlmZmljdWx0 eSAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwoKICAgICAgbyAgUHJvdG9jb2wgSUQgKDEgb2N0ZXQpIC0tIE1VU1QgYmUgMC4KCiAg ICAgIG8gIFNQSSBTaXplICgxIG9jdGV0KSAtIE1VU1QgYmUgMCwgbWVhbmluZyBubyBTZWN1 cml0eSBQYXJhbWV0ZXIKICAgICAgSW5kZXggKFNQSSkgaXMgcHJlc2VudC4KCiAgICAgIG8g IE5vdGlmeSBNZXNzYWdlIFR5cGUgKDIgb2N0ZXRzKSAtLSBNVVNUIGJlIDxUQkEgYnkgSUFO QT4sIHRoZQogICAgICB2YWx1ZSBhc3NpZ25lZCBmb3IgdGhlIFBVWlpMRSBub3RpZmljYXRp b24uCgogICAgICBvICBQUkYgKDIgb2N0ZXRzKSAtLSBUcmFuc2Zvcm0gSUQgb2YgdGhlIFBS RiBhbGdvcml0aG0gdGhhdCBtdXN0CiAgICAgIGJlIHVzZWQgdG8gc29sdmUgdGhlIHB1enps ZS4gIFJlYWRlcnMgc2hvdWxkIHJlZmVyIHRvIHRoZSBzZWN0aW9uCiAgICAgICJUcmFuc2Zv cm0gVHlwZSAyIC0gUHNldWRvLVJhbmRvbSBGdW5jdGlvbiBUcmFuc2Zvcm0gSURzIiBpbgog ICAgICBbSUtFVjItSUFOQV0gZm9yIHRoZSBsaXN0IG9mIHBvc3NpYmxlIHZhbHVlcy4KCiAg ICAgIG8gIERpZmZpY3VsdHkgKDEgb2N0ZXQpIC0tIERpZmZpY3VsdHkgTGV2ZWwgb2YgdGhl IHB1enpsZS4gCiAgICAgIFNwZWNpZmllcyBtaW5pbXVtIG51bWJlciBvZiB0cmFpbGluZyB6 ZXJvIGJpdHMgKFpCQyksIHRoYXQgZWFjaCBvZgogCgoKTmlyICYgU215c2xvdiAmIEJhcnRs ZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAgICAgICAgICAgICAgW1BhZ2UgMjVdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFByb3RlY3Rpb24gZm9yIElLRXYyICAgICAg ICAgICAgICBNYXJjaCAyMDE2CgoKICAgICAgdGhlCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4 cGlyZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDI2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAg ICAgTWFyY2ggMjAxNgoKCiAgICAgIHJlc3VsdHMgb2YgUFJGIG11c3QgY29udGFpbi4gIFZh bHVlIDAgbWVhbnMgdGhhdCB0aGUgUmVzcG9uZGVyCiAgICAgIGRvZXNuJ3QgcmVxdWVzdCBh bnkgc3BlY2lmaWMgZGlmZmljdWx0eSBsZXZlbCBhbmQgdGhlIEluaXRpYXRvciBpcwogICAg ICBmcmVlIHRvIHNlbGVjdCBhcHByb3ByaWF0ZSBkaWZmaWN1bHR5IGxldmVsIG9uIGl0cyBv d24gKHNlZQogICAgICBTZWN0aW9uIDcuMS4xLjEgZm9yIGRldGFpbHMpLgoKICAgVGhpcyBu b3RpZmljYXRpb24gY29udGFpbnMgbm8gZGF0YS4KCiAgICAgIDkuMi4gIFB1enpsZSBTb2x1 dGlvbiBQYXlsb2FkCgogICBUaGUgc29sdXRpb24gdG8gdGhlIHB1enpsZSBpcyByZXR1cm5l ZCBiYWNrIHRvIHRoZSBSZXNwb25kZXIgaW4gYQogICBkZWRpY2F0ZWQgcGF5bG9hZCwgY2Fs bGVkIHRoZSBQdXp6bGUgU29sdXRpb24gcGF5bG9hZCBhbmQgZGVub3RlZCBhcwogICBQUyBp biB0aGlzIGRvY3VtZW50LgoKICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICB8IE5leHQgUGF5bG9hZCAgfEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXls b2FkIExlbmd0aCAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB+ ICAgICAgICAgICAgICAgICAgICAgUHV6emxlIFNvbHV0aW9uIERhdGEgICAgICAgICAgICAg ICAgICAgICAgfgogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICAgbyAgUHV6 emxlIFNvbHV0aW9uIERhdGEgKHZhcmlhYmxlIGxlbmd0aCkgLS0gQ29udGFpbnMgdGhlIHNv bHV0aW9uCiAgICAgIHRvIHRoZSBwdXp6bGUgLSBmb3VyIGRpZmZlcmVudCBrZXlzIGZvciB0 aGUgc2VsZWN0ZWQgUFJGLiAgVGhpcwogICAgICBmaWVsZCBNVVNUIE5PVCBiZSBlbXB0eS4g IEFsbCB0aGUga2V5cyBNVVNUIGhhdmUgdGhlIHNhbWUgc2l6ZSwKICAgICAgdGhlcmVmb3Jl IHRoZSBzaXplIG9mIHRoaXMgZmllbGQgaXMgYWx3YXlzIGEgbXV0aXBsZSBvZiA0IGJ5dGVz LgogICAgICBJZiB0aGUgc2VsZWN0ZWQgUFJGIGFjY2VwdHMgb25seSBmaXhlZC1zaXplIGtl eXMsIHRoZW4gdGhlIHNpemUgb2YKICAgICAgZWFjaCBrZXkgTVVTVCBiZSBvZiB0aGF0IGZp eGVkIHNpemUuICBJZiB0aGUgUFJGIGFncmVlZCB1cG9uCiAgICAgIGFjY2VwdHMga2V5cyBv ZiBhbnkgc2l6ZSwgdGhlbiB0aGVuIHRoZSBzaXplIG9mIGVhY2gga2V5IE1VU1QgYmUKICAg ICAgYmV0d2VlbiAxIG9jdGV0IGFuZCB0aGUgcHJlZmVycmVkIGtleSBsZW5ndGggb2YgdGhl IFBSRgogICAgICAoaW5jbHVzaXZlKS4gIEl0IGlzIGV4cGVjdGVkIHRoYXQgaW4gbW9zdCBj YXNlcyB0aGUga2V5cyB3aWxsIGJlIDQKICAgICAgKG9yIGV2ZW4gbGVzcykgb2N0ZXRzIGlu IGxlbmd0aCwgaG93ZXZlciBpdCBkZXBlbmRzIG9uIHB1enpsZQogICAgICBkaWZmaWN1bHR5 IGFuZCBvbiB0aGUgSW5pdGlhdG9yJ3Mgc3RyYXRlZ3kgdG8gZmluZCBzb2x1dGlvbnMsIGFu ZAogICAgICB0aHVzIHRoZSBzaXplIGlzIG5vdCBtYW5kYXRlZCBieSB0aGlzIHNwZWNpZmlj YXRpb24uICBUaGUKICAgICAgUmVzcG9uZGVyIGRldGVybWluZXMgdGhlIHNpemUgb2YgZWFj aCBrZXkgYnkgZGl2aWRpbmcgdGhlIHNpemUgb2YKICAgICAgdGhlIFB1enpsZSBTb2x1dGlv biBEYXRhIGJ5IDQgKHRoZSBudW1iZXIgb2Yga2V5cykuICBOb3RlIHRoYXQgdGhlCiAgICAg IHNpemUgb2YgUHV6emxlIFNvbHV0aW9uIERhdGEgaXMgdGhlIHNpemUgb2YgUGF5bG9hZCAo YXMgaW5kaWNhdGVkCiAgICAgIGluIFBheWxvYWQgTGVuZ3RoIGZpZWxkKSBtaW51cyA0IC0g dGhlIHNpemUgb2YgUGF5bG9hZCBIZWFkZXIuCgogICBUaGUgcGF5bG9hZCB0eXBlIGZvciB0 aGUgUHV6emxlIFNvbHV0aW9uIHBheWxvYWQgaXMgPFRCQSBieSBJQU5BPi4KCiAgICAgMTAu ICBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucwoKICAgVGhlIGRpZmZpY3VsdHkgbGV2ZWwg c2hvdWxkIGJlIHNldCBieSBiYWxhbmNpbmcgdGhlIHJlcXVpcmVtZW50IHRvCiAgIG1pbmlt aXplIHRoZSBsYXRlbmN5IGZvciBsZWdpdGltYXRlIEluaXRpYXRvcnMgYW5kIG1ha2luZyB0 aGluZ3MKICAgZGlmZmljdWx0IGZvciBhdHRhY2tlcnMuICBBIGdvb2QgcnVsZSBvZiB0aHVt YiBpcyBmb3IgdGFraW5nIGFib3V0IDEKICAgc2Vjb25kIHRvIHNvbHZlIHRoZSBwdXp6bGUu ICBBIHR5cGljYWwgSW5pdGlhdG9yIG9yIGJvdC1uZXQgbWVtYmVyIGluCiAKCgpOaXIgJiBT bXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAg ICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBm b3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICAyMDE0IGNhbiBwZXJmb3Jt IHNsaWdodGx5IGxlc3MgdGhhbiBhIG1pbGxpb24gaGFzaGVzIHBlciBzZWNvbmQgcGVyCiAg IGNvcmUsIHNvIHNldHRpbmcgdGhlIGRpZmZpY3VsdHkgbGV2ZWwgdG8gbj0yMCBpcyBhIGdv b2QgY29tcHJvbWlzZS4KICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgbW9iaWxlIEluaXRp YXRvcnMsIGVzcGVjaWFsbHkgcGhvbmVzIGFyZQogICBjb25zaWRlcmFibHkgd2Vha2VyIHRo YW4gdGhhdC4gIEltcGxlbWVudGF0aW9ucyBzaG91bGQgYWxsb3cKICAgYWRtaW5pc3RyYXRv cnMgdG8gc2V0IHRoZSBkaWZmaWN1bHR5IGxldmVsLCBhbmQvb3IgYmUgYWJsZSB0byBzZXQg dGhlCiAgIGRpZmZpY3VsdHkgbGV2ZWwgZHluYW1pY2FsbHkgaW4gcmVzcG9uc2UgdG8gbG9h ZC4KCiAgIEluaXRpYXRvcnMgc2hvdWxkIHNldCBhIG1heGltdW0gZGlmZmljdWx0eSBsZXZl bCBiZXlvbmQgd2hpY2ggdGhleQogICB3b24ndCB0cnkgdG8gc29sdmUgdGhlIHB1enpsZSBh bmQgbG9nIG9yIGRpc3BsYXkgYSBmYWlsdXJlIG1lc3NhZ2UgdG8KICAgdGhlIGFkbWluaXN0 cmF0b3Igb3IgdXNlci4KCiAgICAgMTEuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAg V2hlbiBzZWxlY3RpbmcgcGFyYW1ldGVycyBmb3IgdGhlIHB1enpsZXMsIGluIHBhcnRpY3Vs YXIgdGhlIHB1enpsZQogICBkaWZmaWN1bHR5LCBjYXJlIG11c3QgYmUgdGFrZW4uICBJZiB0 aGUgcHV6emxlcyBhcHBlYXJlZCB0b28gZWFzeSBmb3IKICAgbWFqb3JpdHkgb2YgdGhlIGF0 dGFja2VycywgdGhlbiB0aGUgcHV6emxlcyBtZWNoYW5pc20gd291bGRuJ3QgYmUKICAgYWJs ZSB0byBwcmV2ZW50IERvUyBhdHRhY2sgYW5kIHdvdWxkIG9ubHkgaW1wb3NlIGFuIGFkZGl0 aW9uYWwgYnVyZGVuCiAgIG9uIHRoZSBsZWdpdGltYXRlIEluaXRpYXRvcnMuICBPbiB0aGUg b3RoZXIgaGFuZCwgaWYgdGhlIHB1enpsZXMKICAgYXBwZWFyZWQgdG8gYmUgdG9vIGhhcmQg Zm9yIG1ham9yaXR5IG9mIHRoZSBJbml0aWF0b3JzIHRoZW4gbWFueQogICBsZWdpdGltYXRl IHVzZXJzIHdvdWxkIGV4cGVyaWVuY2UgdW5hY2NlcHRhYmxlIGRlbGF5IGluIElLRSBTQSBz ZXR1cAogICAob3IgdW5hY2NlcHRhYmxlIHBvd2VyIGNvbnN1bXB0aW9uIG9uIG1vYmlsZSBk ZXZpY2VzKSwgdGhhdCBtaWdodAogICBjYXVzZSB0aGVtIHRvIGNhbmNlbCBjb25uZWN0aW9u IGF0dGVtcHQuICBJbiB0aGlzIGNhc2UgdGhlIHJlc291cmNlcwogICBvZiB0aGUgUmVzcG9u ZGVyIGFyZSBwcmVzZXJ2ZWQsIGhvd2V2ZXIgdGhlIERvUyBhdHRhY2sgY2FuIGJlCiAgIGNv bnNpZGVyZWQgc3VjY2Vzc2Z1bC4gIFRodXMgYSBzZW5zaWJsZSBiYWxhbmNlIHNob3VsZCBi ZSBrZXB0IGJ5IHRoZQogICBSZXNwb25kZXIgd2hpbGUgY2hvb3NpbmcgdGhlIHB1enpsZSBk aWZmaWN1bHR5IC0gdG8gZGVmZW5kIGl0c2VsZiBhbmQKICAgdG8gbm90IG92ZXItZGVmZW5k IGl0c2VsZi4gIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIHB1enpsZQogICBkaWZmaWN1 bHR5IGJlIGNob3NlbiBzbywgdGhhdCB0aGUgUmVzcG9uZGVyJ3MgbG9hZCByZW1haW4gY2xv c2UgdG8KICAgdGhlIG1heGltdW0gaXQgY2FuIHRvbGVyYXRlLiAgSXQgaXMgYWxzbyBSRUNP TU1FTkRFRCB0byBkeW5hbWljYWxseQogICBhZGp1c3QgdGhlIHB1enpsZSBkaWZmaWN1bHR5 IGluIGFjY29yZGFuY2UgdG8gdGhlIGN1cnJlbnQgUmVzcG9uZGVyJ3MKICAgbG9hZC4KCiAg IFNvbHZpbmcgcHV6emxlcyByZXF1aXJlcyBhIGxvdCBvZiBDUFUgcG93ZXIsIHRoYXQgd291 bGQgaW5jcmVhc2UKICAgcG93ZXIgY29uc3VtcHRpb24uICBUaGlzIHdvdWxkIGluZmx1ZW5j ZSBiYXR0ZXJ5LXBvd2VyZWQgSW5pdGlhdG9ycywKICAgZS5nLiBtb2JpbGUgcGhvbmVzIG9y IHNvbWUgSW9UIGRldmljZXMuICBJZiBwdXp6bGVzIGFyZSBoYXJkIHRoZW4gdGhlCiAgIHJl cXVpcmVkIGFkZGl0aW9uYWwgcG93ZXIgY29uc3VtcHRpb24gbWF5IGFwcGVhciB0byBiZSB1 bmFjY2VwdGFibGUKICAgZm9yIHNvbWUgSW5pdGlhdG9ycy4gIFRoZSBSZXNwb25kZXIgU0hP VUxEIHRha2UgdGhpcyBwb3NzaWJpbGl0eSBpbnRvCiAgIGNvbnNpZGVyYXRpb25zIHdoaWxl IGNob29zaW5nIHRoZSBwdXp6bGVzIGRpZmZpY3VsdHkgYW5kIHdoaWxlCiAgIHNlbGVjdGlu ZyB3aGljaCBwZXJjZW50YWdlIG9mIEluaXRpYXRvcnMgYXJlIGFsbG93ZWQgdG8gcmVqZWN0 CiAgIHNvbHZpbmcgcHV6emxlcy4gIFNlZSBTZWN0aW9uIDcuMS40IGZvciBkZXRhaWxzLgoK ICAgSWYgdGhlIEluaXRpYXRvciB1c2VzIE5VTEwgQXV0aGVudGljYXRpb24gW1JGQzc2MTld IHRoZW4gaXRzIGlkZW50aXR5CiAgIGlzIG5ldmVyIHZlcmlmaWVkLCB0aGF0IG1heSBiZSB1 c2VkIGJ5IGF0dGFja2VycyB0byBwZXJmb3JtIERvUwogICBhdHRhY2sgYWZ0ZXIgSUtFIFNB IGlzIGVzdGFibGlzaGVkLiAgUmVzcG9uZGVycyB0aGF0IGFsbG93CiAgIHVuYXV0aGVudGlj YXRlZCBJbml0aWF0b3JzIHRvIGNvbm5lY3QgbXVzdCBiZSBwcmVwYXJlZCBkZWFsIHdpdGgK ICAgdmFyaW91cyBraW5kcyBvZiBEb1MgYXR0YWNrcyBldmVuIGFmdGVyIElLRSBTQSBpcyBj cmVhdGVkLiAgU2VlCiAgIFNlY3Rpb24gOCBmb3IgZGV0YWlscy4KCiAgIFdoZW4gcGVyZm9y bWluZyBhIHBvbGljeSBsb29rdXAgdXNpbmcgdGhlIElkZW50aXR5IHBheWxvYWQgY2FyZQog CgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFBy b3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKICAgc2hvdWxk IGJlIHRha2VuIHRvIGVuc3VyZSB0aGF0IHRoZSBwcmVzZW50ZWQgaWRlbnRpdHkgYmVsb25n cyB0byB0aGUKICAgcGVlciBpbiBxdWVzdGlvbi4gVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkg dXNpbmcgYSB1bmlxdWUgc2hhcmVkLQogICBzZWNyZXQgcGVyIHBlZXIgd2hlbiB1c2luZyBw cmUtc2hhcmVkLWtleSBhdXRoZW50aWNhdGlvbi4gV2hlbgogICBhdXRoZW50aWNhdGlvbiBp cyBwZXJmb3JtZWQgdXNpbmcgZGlnaXRhbCBzaWduYXR1cmVzIHRoZSBwcmVzZW50ZWQKICAg SWRlbnRpdHkgc2hvdWxkIGJlIGNvbnRhaW5lZCB3aXRoaW4gdGhlIGNlcnRpZmljYXRlIGFu ZAogICBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHBlcmZvcm0gYSBjaGVjayB0byB2YWxpZGF0 ZSB0aGF0IHRoaXMgb2NjdXJzLgoKICAgVG8gcHJldmVudCBhbXBsaWZpY2F0aW9uIGF0dGFj a3MgdGhlIFJlc3BvbmRlciBtdXN0IHJldHJhbnNtaXQgdGhlCiAgIHJlc3BvbnNlIG1lc3Nh Z2Ugb25seSBpZiBpdCByZWNlaXZlcyBhIHJldHJhbnNtaXR0ZWQgcmVxdWVzdCBmcm9tIHRo ZQogICBJbml0aWF0b3IsIGFuZCBtdXN0IG5vdCBkbyBpdCB1bmRlciBhbnkgb3RoZXIgY2ly Y3Vtc3RhbmNlcy4gTm90ZSwKICAgdGhhdCB0aGlzIGJlaGF2aW9yIGlzIGFscmVhZHkgcHJl c2NyaWJlZCBpbiBTZWN0aW9uIDIuMSBvZiBSRkM3Mjk2LgogICBUaGUgb25seSB0aW1lIGEg UmVzcG9uZGVyIHNob3VsZCByZXBseSB0byBhbiBTQV9JTklUIHdpdGggYW4KICAgSU5GT1JN QVRJT05BTCBtZXNzYWdlIGlzIGR1ZSB0byBhIHZlcnNpb24gbWlzbWF0Y2hlZC4gVGhpcyBp cwogICBwcmVzY3JpYmVkIGluIFNlY3Rpb25zIDEuNCBhbmQgMS41IG9mIFJGQzcyOTYuIAoK ICAgUkZDNzI5NiBkZXNjcmliZXMgdGhlIHVzZSBvZiBhIEhBU0ggYW5kIFVSTCB0byBiZSBz ZW50IGluIHBsYWNlIG9mIGEKICAgY2VydGlmaWNhdGUuIFRoZSB1c2Ugb2YgdGhlIEhBU0gg YW5kIFVSTCBpcyBlbmNvdXJhZ2VkIHRvIG92ZXJjb21lCiAgIGNvbm5lY3Rpdml0eSBpc3N1 ZXMgZHVlIHRvIGZyYWdtZW50YXRpb24gYW5kIGltcHJvdmUgZWZmaWNpZW5jeSB3aGVuCiAg IHNlbmRpbmcgbGFyZ2UgY2VydGlmaWNhdGVzLiAKCiAgIFdoZW4gYSBjbGllbnQgaXMgdXNp bmcgdGhlIEhBU0ggYW5kIFVSTCBtZXRob2QgaW5zdGVhZCBvZiBzZW5kaW5nIGEKICAgY2Vy dGlmaWNhdGUsIHRoZSBlbXBoYXNpcyBpcyBvbiB0aGUgVlBOIGdhdGV3YXkgdG8gcmV0cmll dmUgdGhlCiAgIGNlcnRpZmljYXRlIGFuZCB0aGVuIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50 LiBUaGlzIGJlaGF2aW9yIGlzCiAgIGNvbnRyYXJ5IHRvIHRoZSBjbGllbnQgc2VuZGluZyBp dHMgb3duIGNlcnRpZmljYXRlLCB3aGljaCBpcyB0aGUKICAgcmVzcG9uc2liaWxpdHkgb2Yg dGhlIGNsaWVudC4gQmVjYXVzZSB0aGUgZW1waGFzaXMgaXMgb24gdGhlIFZQTgogICBnYXRl d2F5IHRvIHJldHJpZXZlIHRoZSBjZXJ0aWZpY2F0ZSBtYWxpY2lvdXMgY2xpZW50cyBjYW4g dXNlIHRoaXMgYXMKICAgYSBtZXRob2QgZm9yIERvUyBjb25kaXRpb25zLgoKICAgQmVjYXVz ZSBtYW55IGltcGxlbWVudGF0aW9uIGRvIG5vdCB1c2UgdGhlIEhBU0ggYW5kIFVSTCwKICAg aW1wbGVtZW50YXRpb25zIHNob3VsZCBoYXZlIHRoZSBhYmlsaXR5IHRvIGRpc2FibGUgdGhl IHVzZSBvZiBIQVNICiAgIGFuZCBVUkwgaWYgdGhpcyBmZWF0dXJlIGlzIG5vdCBjb25maWd1 cmVkLiBUaGlzIHdpbGwgbWluaW1pemUgdGhlCiAgIGltcGFjdCBvZiBkYW1hZ2UgZnJvbSBt YWxpY2lvdXMgdXNlLgoKICAgQSBudW1iZXIgb2YgYXR0YWNrcyBjYW4gb2NjdXIgaWYgaW1w bGVtZW50YXRpb25zIHVzZSB0aGUgSEFTSCBhbmQKICAgVVJMLiBSYXRoZXIgdGhhbiBzZW5k aW5nIGEgbGVnaXRpbWF0ZSBIQVNIIGFuZCBVUkwsIG1hbGljaW91cyBwYXJ0aWVzCiAgIGNh biBzZW5kIGEgVVJMIHRvIHJlZGlyZWN0IGEgVlBOIGdhdGV3YXkgdG8gYSBzZXJ2ZXIgd2hp Y2ggZG9lcyBub3QKICAgY29udGFpbiBhIGNlcnRpZmljYXRlIG1hdGNoaW5nIHRoZSBIQVNI LCBidXQgaW5zdGVhZCBjb250YWlucyBhIGxhcmdlCiAgIGZpbGUgdGhhdCBpcyB0aGVuIGRv d25sb2FkZWQgYnkgdGhlIFZQTiBnYXRld2F5IGNvbnN1bWluZyBDUFUgYW5kCiAgIG1lbW9y eS4gRm9yIHRoaXMgcmVhc29uIHRoZSBzaXplIG9mIGNlcnRpZmljYXRlIHJldHJpZXZlZCBi eSB0aGUKICAgc2VydmVyIHNob3VsZCBiZSBsaW1pdGVkIGJ5IHRoZSBzaXplIG9mIHRoZSBj ZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5CiAgIHRoZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkuIFRo ZSBWUE4gZ2F0ZXdheSBzaG91bGQgYmUgY29uZmlndXJhYmxlIHRvCiAgIG9ubHkgcmV0cmll dmUgVVJMcyBmcm9tIGtub3duIGdvb2Qgc291cmNlcywgdGhlcmUgaXMgbm8gcmVhc29uIHRo YXQKICAgdGhlIFZQTiBnYXRld2F5IGF0dGVtcHRzIHRvIHJldHJpZXZlIGEgY2VydGlmaWNh dGUgZnJvbSBhIGxvY2F0aW9uCiAgIHRoYXQgaXMgbm90IGtub3duIHRvIGJlIGEgcmVwb3Np dG9yeSBvZiBjZXJ0aWZpY2F0ZXMuCgogICBNYWxpY2lvdXMgb3IgbWlzLWNvbmZpZ3VyZWQg Y2xpZW50cyBjYW4gbWFrZSBudW1lcm91cyByZXF1ZXN0cyB0aGF0CiAgIGV4aGF1c3QgdGhl IEhUVFAgb3IgVENQIGRhZW1vbiBydW5uaW5nIG9uIHRoZSBWUE4gZ2F0ZXdheS4gVGhlIGFt b3VudAogICBvZiByZXF1ZXN0cyB0aGF0IGFyZSBwZXJmb3JtZWQgaW4gYSBnaXZlbiB0aW1l IHNob3VsZCBiZSBtb25pdG9yZWQKIAoKCk5pciAmIFNteXNsb3YgJiBCYXJ0bGV0dEV4cGly ZXMgU2VwdGVtYmVyIDksIDIwMTYgICAgICAgICAgICAgIFtQYWdlIDI5XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgRERvUyBQcm90ZWN0aW9uIGZvciBJS0V2MiAgICAgICAgICAgICAg TWFyY2ggMjAxNgoKCiAgIGFuZCByYXRlIGxpbWl0ZWQgc2hvdWxkIEhUVFAgY29ubmVjdGlv bnMgZmFpbC4gVGhlIFZQTiBnYXRld2F5CiAgIGFyY2hpdGVjdHVyZSBzaG91bGQgYmUgZGVz aWduZWQgc28gdGhhdCB0aGUgcmVwb3NpdG9yeSBjb250YWluaW5nCiAgIGNlcnRpZmljYXRl cyBpcyBub3QgYWNjZXNzaWJsZSBieSB1c2VycyBvZiB0aGUgVlBOIGFuZCBzaG91bGQgYmUg b24KICAgYW4gb3V0IG9mIGJhbmQgaW50ZXJmYWNlLiBUaGlzIG1pbmltaXplcyB0aGUgcmlz ayBvZiB0aGUgcmVwb3NpdG9yeQogICBiZWluZyBjb21wcm9taXNlZCBhbmQgYXR0YWNrcyBz dWNoIGFzIG9wZW5pbmcgc29ja2V0cyBhbmQgdGhlbgogICBzZXR0aW5nIGEgemVybyB3aW5k b3cgc2l6ZSBiZWluZyBwZXJmb3JtZWQuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCiAKCgpOaXIgJiBTbXlzbG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRl bWJlciA5LCAyMDE2ICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3IgSUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIw MTYKCgoxMi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIG5ldyBwYXlsb2FkIGluIHRoZSAiSUtFdjIgUGF5bG9hZCBUeXBlcyIKICAgcmVnaXN0 cnk6CgogICAgIDxUQkE+ICAgICAgIFB1enpsZSBTb2x1dGlvbiAgICAgICAgICAgICAgICAg ICBQUwoKICAgVGhpcyBkb2N1bWVudCBhbHNvIGRlZmluZXMgYSBuZXcgTm90aWZ5IE1lc3Nh Z2UgVHlwZSBpbiB0aGUgIklLRXYyCiAgIE5vdGlmeSBNZXNzYWdlIFR5cGVzIC0gU3RhdHVz IFR5cGVzIiByZWdpc3RyeToKCiAgICAgPFRCQT4gICAgICAgUFVaWkxFCgogICAgIDEzLiAg QWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgdGhhbmsgVGVybyBLaXZpbmVuLCBZ YXJvbiBTaGVmZmVyIGFuZCBTY290dCBGbHVocmVyIGZvcgogICB0aGVpciBjb250cmlidXRp b24gaW50byBkZXNpZ24gb2YgdGhlIHByb3RvY29sLiAgSW4gcGFydGljdWxhciwgVGVybwog ICBLaXZpbmVuIHN1Z2dlc3RlZCB0aGUga2luZCBvZiBwdXp6bGUgd2hlcmUgdGhlIHRhc2sg aXMgdG8gZmluZCBhCiAgIHNvbHV0aW9uIHdpdGggcmVxdWVzdGVkIG51bWJlciBvZiB6ZXJv IHRyYWlsaW5nIGJpdHMuICBZYXJvbiBTaGVmZmVyCiAgIGFuZCBTY290dCBGbHVocmVyIHN1 Z2dlc3RlZCBhIHdheSB0byBtYWtlIHB1enpsZSBkaWZmaWN1bHR5IGxlc3MKICAgZXJyYXRp YyBieSBzb2x2aW5nIHNldmVyYWwgd2Vha2VyIHB1emxlcy4gIFRoZSBhdXRob3JzIGFsc28g dGhhbmsKICAgRGF2aWQgV2FsdGVybWlyZSBmb3IgaGlzIGNhcmVmdWxsIHJldmlldyBvZiB0 aGUgZHJhZnQgYW5kIGFsbCBvdGhlcnMKICAgd2hvIGNvbW1lbnRlZCB0aGUgZG9jdW1lbnQu CgogICAgIDE0LiAgUmVmZXJlbmNlcwoKICAgICAgIDE0LjEuICBOb3JtYXRpdmUgUmVmZXJl bmNlcwoKICAgICAgICAgICAgICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRz IGZvciB1c2UgaW4gUkZDcyB0bwogICAgICAgICAgICAgIEluZGljYXRlIFJlcXVpcmVtZW50 IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3 L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgICAgICAgICAgICAgW1JGQzcyOTZdICBLYXVm bWFuLCBDLiwgSG9mZm1hbiwgUC4sIE5pciwgWS4sIEVyb25lbiwgUC4sCiAgICAgICAgICAg ICAgYW5kIFQuIEtpdmluZW4sICJJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVy c2lvbiAyCiAgICAgICAgICAgICAgKElLRXYyKSIsIFNURCA3OSwgUkZDIDcyOTYsIERPSSAx MC4xNzQ4Ny9SRkM3Mjk2LCBPY3RvYmVyCiAgICAgICAgICAgICAgMjAxNCwgPGh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3Mjk2Pi4KCiAgICAgICAgICAgICAgW1JGQzcz ODNdICBTbXlzbG92LCBWLiwgIkludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbAogICAg ICAgICAgICAgIFZlcnNpb24gMiAoSUtFdjIpIE1lc3NhZ2UgRnJhZ21lbnRhdGlvbiIsIFJG QyA3MzgzLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3MzgzLCBOb3ZlbWJlciAy MDE0LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj NzM4Mz4uCgogICBbSUtFVjItSUFOQV0KICAgICAgICAgICAgICAiSW50ZXJuZXQgS2V5IEV4 Y2hhbmdlIFZlcnNpb24gMiAoSUtFdjIpIFBhcmFtZXRlcnMiLAogICAgICAgICAgICAgIDxo dHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lrZXYyLXBhcmFtZXRlcnM+LgoKCgog CgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBERG9TIFBy b3RlY3Rpb24gZm9yIElLRXYyICAgICAgICAgICAgICBNYXJjaCAyMDE2CgoKMTQuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtiaXRjb2luc10KICAgICAgICAgICAgICBOYWth bW90bywgUy4sICJCaXRjb2luOiBBIFBlZXItdG8tUGVlciBFbGVjdHJvbmljIENhc2gKICAg ICAgICAgICAgICBTeXN0ZW0iLCBPY3RvYmVyIDIwMDgsIDxodHRwczovL2JpdGNvaW4ub3Jn L2JpdGNvaW4ucGRmPi4KCiAgICAgICAgICAgICAgW1JGQzU3MjNdICBTaGVmZmVyLCBZLiBh bmQgSC4gVHNjaG9mZW5pZywgIkludGVybmV0IEtleQogICAgICAgICAgICAgIEV4Y2hhbmdl IFByb3RvY29sIFZlcnNpb24gMiAoSUtFdjIpIFNlc3Npb24gUmVzdW1wdGlvbiIsCiAgICAg ICAgICAgICAgUkZDIDU3MjMsIERPSSAxMC4xNzQ4Ny9SRkM1NzIzLCBKYW51YXJ5IDIwMTAs CiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1NzIz Pi4KCiAgICAgICAgICAgICAgW1JGQzc2MTldICBTbXlzbG92LCBWLiBhbmQgUC4gV291dGVy cywgIlRoZSBOVUxMCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gTWV0aG9kIGluIHRo ZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UKICAgICAgICAgICAgICBQcm90b2NvbCBWZXJzaW9u IDIgKElLRXYyKSIsIFJGQyA3NjE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3 NjE5LCBBdWd1c3QgMjAxNSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzc2MTk+LgoKICAgICAgICAgICAgICBbUkZDNzY5Nl0gIEhvdXNsZXks IFIuLCAiR3VpZGVsaW5lcyBmb3IgQ3J5cHRvZ3JhcGhpYwogICAgICAgICAgICAgIEFsZ29y aXRobSBBZ2lsaXR5IGFuZCBTZWxlY3RpbmcgTWFuZGF0b3J5LXRvLUltcGxlbWVudAogICAg ICAgICAgICAgIEFsZ29yaXRobXMiLCBCQ1AgMjAxLCBSRkMgNzY5NiwgRE9JIDEwLjE3NDg3 L1JGQzc2OTYsCiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxNSwgPGh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmM3Njk2Pi4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgWW9h diBOaXIKICAgQ2hlY2sgUG9pbnQgU29mdHdhcmUgVGVjaG5vbG9naWVzIEx0ZC4KICAgNSBI YXNvbGVsaW0gc3QuCiAgIFRlbCBBdml2ICA2Nzg5NzM1CiAgIElzcmFlbAoKICAgRU1haWw6 IHluaXIuaWV0ZkBnbWFpbC5jb20KCgogICBWYWxlcnkgU215c2xvdgogICBFTFZJUy1QTFVT CiAgIFBPIEJveCA4MQogICBNb3Njb3cgKFplbGVub2dyYWQpICAxMjQ0NjAKICAgUnVzc2lh biBGZWRlcmF0aW9uCgogICBQaG9uZTogKzcgNDk1IDI3NiAwMjExCiAgIEVNYWlsOiBzdmFu QGVsdmlzLnJ1CgoKICAgR3JhaGFtIEJhcnRsZXR0CiAgIENpc2NvIFN5c3RlbXMKICAgMzAw IExvbmd3YXRlciBBdmVudWUKICAgUmVhZGluZwogICBFbmdsYW5kCiAKCgpOaXIgJiBTbXlz bG92ICYgQmFydGxldHRFeHBpcmVzIFNlcHRlbWJlciA5LCAyMDE2ICAgICAgICAgICAgICBb UGFnZSAzMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEREb1MgUHJvdGVjdGlvbiBmb3Ig SUtFdjIgICAgICAgICAgICAgIE1hcmNoIDIwMTYKCgogICBFTWFpbDogZ3JiYXJ0bGVAY2lz Y28uY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKTmlyICYgU215c2xvdiAmIEJhcnRsZXR0RXhwaXJlcyBTZXB0ZW1iZXIgOSwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMzNdCg== --B_3541183643_879632-- --B_3541183643_855846 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgz7Ch vMBJmpPvXUtUONQwTg7DaS69uX8B/ZGAuJXpYSkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE4MjIwNzIzWjANBgkqhkiG9w0BAQEFAASCAQClsPMD xnFGv3aVwiVgdYUL+diCfNCxGBO/2tqbaa9MUUI6Dr59/Jg35JlXx4ZeXVgzZkF+VChF9avi hZFjbtMTfKeTGtIG560y2KANd4WXHSRNsj+KN2FJ4fgeWPp2a0+OfoQOxK2nxhVlpM8qI03I hUVAaOKwFFYU+zLON8lu8xsPN8C9YT87sxBwl055+vfYnePOQhR/mZNENqJfLlKaM3OzzTmk 9cBfJxWpCWt/GypeI/1Zfn9eLxThpVQbcE+HSk3qBzqJru1ab48YxDyhw+tv0t0FLxFGqFtN xTWqIw9mBz48CZ8A7MapGNsoMQaKZzxMyPHsIDhG2wkR+We3 --B_3541183643_855846-- From nobody Sat Mar 19 23:43:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55712D617 for ; Sat, 19 Mar 2016 23:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 K_D4jmv9vAwJ for ; Sat, 19 Mar 2016 23:43:10 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E07912D565 for ; Sat, 19 Mar 2016 23:43:10 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h198so89920999lfh.0 for ; Sat, 19 Mar 2016 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=p4RbGA+5ww4Ne0chn9LxJCdXO9mq7IUFsG11QG1AhMY=; b=fqd/JmkwIlfzDA2+NvT5xT4oeSZEVfX9dbCK3O83Wsx9vmCAvQZCmu8OddWz3slcpC 7MqxdfsTdI8sK8tRbhfAHZqxaGEcvkKiNCcax3ovOWWMHMyoWWYPC7hF4/8TH0q5sKG5 T3F6QBvEyAWkQi6dyyDyNC/UEAysfXLnA3VdGNcI1Y3Sh0iuBBiraqfGNeT7tpgMuYQ1 8JhoPostJsgMRHhcEkxuNRd+XrQAW+icC8eGhIRdnhUj+bm+qXwW8EXot4ktupWa3nCJ zP+rixwF5gZM3xUcW7SjZF4eETLMThF5pVOEuANSQvqQ0fk4NLaf34fyXzcpb6BD/gmd 3vpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=p4RbGA+5ww4Ne0chn9LxJCdXO9mq7IUFsG11QG1AhMY=; b=Z8UWjIWY0B0fk7ZdJxK4sG9bXM9gyVZiIkFFRwxle7HGMX1MoYh2L9ch722nTQvkq2 fdW6oAZavYTQ7js1JwZkj39+67p4CVnXHiEHp/Hgg5AI2iYdSZsiEaUjLpFskQVojBLd 4g5TUAen63KKtWV/+tcF75vPhVzFYnV26FpgTCjIL9i1edJdT2MxsgyM5/GktAWqLwUo xKtlZ0T13RG972o1d8gJgZAjt/PDr/j0jjqWUW6F7tK8Ce3tfujgVIU4goMKrYLShK9N wkL3buUD4mbCZKBpl+I0rr9LvLi3tYjj8ghEg30fwa94IXF/AmvUm4SV8OBC5WUrQPZZ spxw== X-Gm-Message-State: AD7BkJIw04qMP6mDiI34rwRtbWjaXCxsd//3Z7qdb8bcdthzdiaBaf29+lsaNWnkWC5KdQ== X-Received: by 10.25.147.209 with SMTP id v200mr8765651lfd.154.1458456188387; Sat, 19 Mar 2016 23:43:08 -0700 (PDT) Received: from chichi (ppp83-237-36-235.pppoe.mtu-net.ru. [83.237.36.235]) by smtp.gmail.com with ESMTPSA id h192sm3573572lfb.45.2016.03.19.23.43.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Mar 2016 23:43:07 -0700 (PDT) Message-ID: <8E7A385FFC124F60A313BB202FC81979@chichi> From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Waltermire, David A. \(Fed\)" , "IPsecME WG" References: In-Reply-To: Date: Sun, 20 Mar 2016 09:43:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 06:43:12 -0000 Hi Graham, thank you for the updated text. > I¹ve made some amendments to the proposed text based on Valerys comments. > > I¹ve also added text around the correct sending of INFORMATIONAL messages > due to a Responder receiving an SA_INIT, this is a known problem today > with a number of implementations. (seen by Tero and myself). Sorry, your text is wrong (or at least is not accurate). The responder must never reply to an IKE_SA_INIT with INFORMATIONAL message. See section 1.5 of RFC 7296: In the second and third cases, the message is always sent without cryptographic protection (outside of an IKE SA), and includes either an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no notification data). The message is a response message, and thus it is sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID and Exchange Type are copied from the request. The Response flag is set to 1, and the version flags are set in the normal fashion. Note, thet Exchange Type is copied from the request, so if some IKE_SA_INIT request has unsupported major version the responder will send INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response. The only case unprotected INFORMATIONAL message is sent is when the host receives AH/ESP packet with unknown SPI. And all these cases are covered in Section 1.5 of RFC 7296 in sufficient detail, including DoS attacks prevention measures (rate limiting). I don't think we should repeat all this in the draft. > I have also moved text to section 11. Security Consideration. > > I¹ve added some words around the checking of the IDi/IDr. I¹ve personally > seen some issues when misconfigured clients have presented an identical > IDi, resulting in INITIAL_CONTACT deleting the Œother¹ clients SA. Since INITIAL_CONTACT is processed after peer authentication, malicious user cannot use it to perform DoS attack (unless he/she is able to impersonate legitimate user, but in this case he/she can do much worse things). And what about misconfiguration - Section 2.4 of RFC 7296 already has all due warnings: This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time). Again, I don't think we should copy all the requirements concerning INITIAL_CONTACT from RFC7296. > I did think about exhaustion of IP addresses when using configuration > payload to allocate clients IPs, if a malicious or misconfigured client > could exhaust the pool. But I feel the wording in section 8 covers this. > Unless others think otherwise? Again, allocation of IP addresses takes place after user authentication, so it cannot be used as DoS attack by malicious user. > cheers Regards, Valery. From nobody Sun Mar 20 10:20:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6ED12D6E0 for ; Sun, 20 Mar 2016 10:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 wUY8VxPc8w0e for ; Sun, 20 Mar 2016 10:20:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 BC2FF12D63B for ; Sun, 20 Mar 2016 10:20:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qSm1W46qvz3LZ; Sun, 20 Mar 2016 18:20:15 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BBk-ttlfyKiN; Sun, 20 Mar 2016 18:20:14 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 20 Mar 2016 18:20:14 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C4DCF6019B73; Sun, 20 Mar 2016 13:20:13 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca C4DCF6019B73 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BFDFE26087; Sun, 20 Mar 2016 13:20:13 -0400 (EDT) Date: Sun, 20 Mar 2016 13:20:13 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <8E7A385FFC124F60A313BB202FC81979@chichi> Message-ID: References: <8E7A385FFC124F60A313BB202FC81979@chichi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 17:20:20 -0000 On Sun, 20 Mar 2016, Valery Smyslov wrote: >> I¹ve also added text around the correct sending of INFORMATIONAL messages >> due to a Responder receiving an SA_INIT, this is a known problem today >> with a number of implementations. (seen by Tero and myself). I know all versions of openswan and libreswan upto version 3.15 have that problem. > Sorry, your text is wrong (or at least is not accurate). The responder > must never reply to an IKE_SA_INIT with INFORMATIONAL message. > See section 1.5 of RFC 7296: Valery is right. > The only case unprotected INFORMATIONAL message is sent is when > the host receives AH/ESP packet with unknown SPI. And all these cases > are covered in Section 1.5 of RFC 7296 in sufficient detail, including > DoS attacks prevention measures (rate limiting). (off-topic: I don't think Linux supports this....) > I don't think we should repeat all this in the draft. Agreed. > Again, I don't think we should copy all the requirements concerning > INITIAL_CONTACT from RFC7296. Agreed. >> I did think about exhaustion of IP addresses when using configuration >> payload to allocate clients IPs, if a malicious or misconfigured client >> could exhaust the pool. But I feel the wording in section 8 covers this. >> Unless others think otherwise? > > Again, allocation of IP addresses takes place after user authentication, > so it cannot be used as DoS attack by malicious user. That's not entire true for NULL AUTH, but I think those corner cases are discussed in RFC-7619 (null auth) itself and don't need to be repeated here. Paul From nobody Sun Mar 20 14:25:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B15012D52E for ; Sun, 20 Mar 2016 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 sUyrcsLP7dHM for ; Sun, 20 Mar 2016 14:25:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8E712D505 for ; Sun, 20 Mar 2016 14:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12313; q=dns/txt; s=iport; t=1458509118; x=1459718718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iSNAgLTevLKEAAcVlf+LQzTRshLJai1Ioj9tZfZAuZY=; b=c5qb9KooV1Sev7o7fRehpum9JacjOFaN++KCeBYbXBXRhFU24zlPjw// YufKwCtiQDwIG0t0d+WQoIRuwyUlvvPyyXGGhpzefIPrrkk9HFamWelLY LOYf6NAj20O2EklIvJYWDG7ctFoB3IivDZ4N4sggsJOnPxfXVRv5XdRxW E=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAwDHFO9W/5hdJa1dgzOBAUQGrk+JP?= =?us-ascii?q?oIPDoFvhg0CJXs4FAEBAQEBAQFkJ4RCAQEDASNWEAIBCBIwAgICHxEXDgIEAQ0?= =?us-ascii?q?FDogEAwoIr0eKEw2EYgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0Ihh6ERII+gVg8g?= =?us-ascii?q?mqCVgWXJjEBgx2BZocLgXWBZYdxhTGHMYdUAR4BQ4IDBRSBSWqIWj1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,367,1454976000"; d="p7s'?scan'208";a="82679746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2016 21:25:17 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2KLPGnJ025766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 20 Mar 2016 21:25:17 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 20 Mar 2016 16:25:16 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Sun, 20 Mar 2016 16:25:16 -0500 From: "Graham Bartlett (grbartle)" To: Paul Wouters , IPsecME WG , "Waltermire, David A. (Fed)" , Valery Smyslov Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AQHRgWKQEN1mpUdbReie8Bmkunv/FZ9iOI+AgAD2dYA= Date: Sun, 20 Mar 2016 21:25:16 +0000 Message-ID: References: <8E7A385FFC124F60A313BB202FC81979@chichi> In-Reply-To: <8E7A385FFC124F60A313BB202FC81979@chichi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3541353911_2174550" MIME-Version: 1.0 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 21:25:20 -0000 --B_3541353911_2174550 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Valery / Paul Paul - does your implementation send the INFORMATIONAL + other messages (Private Use Error) to a single SA_INIT? Just to clarify the issue observed seemed to be SA_INIT is sent by Initiator, Responder sends an SA_INIT reply plus numerous INFORMATIONAL messages separately to this single SA_INIT message containing Private Use Errors. GB> I=E2=80=99ve made some comments inline for clarity. cheers On 20/03/2016 06:43, "Valery Smyslov" wrote: >Hi Graham, > >thank you for the updated text. > >> I=C2=B9ve made some amendments to the proposed text based on Valerys >>comments. >> >> I=C2=B9ve also added text around the correct sending of INFORMATIONAL >>messages >> due to a Responder receiving an SA_INIT, this is a known problem today >> with a number of implementations. (seen by Tero and myself). > >Sorry, your text is wrong (or at least is not accurate). The responder >must never reply to an IKE_SA_INIT with INFORMATIONAL message. >See section 1.5 of RFC 7296: > > In the second and third cases, the message is always sent without > cryptographic protection (outside of an IKE SA), and includes either > an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no > notification data). The message is a response message, and thus it > is sent to the IP address and port from whence it came with the same > IKE SPIs and the Message ID and Exchange Type are copied from the > request. The Response flag is set to 1, and the version flags are > set in the normal fashion. > >Note, thet Exchange Type is copied from the request, so if some >IKE_SA_INIT >request has unsupported major version the responder will send >INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response. GB> Thanks Valery - this is now clear. However not only was I confused, as Paul confirms there=E2=80=99s other implementations that are also confused. Seein= g as there=E2=80=99s confusion with regards to this wording and it can lead to an amplification attack I personally feel we should include the following text for clarification? "RFC7296 Section 1.5 describes the generating of informational messages a Responder will send. Only a single instance of the generated message should ever be sent for a received request and under no circumstances should a received request cause the generation of more than a single message in reply." =20 > >The only case unprotected INFORMATIONAL message is sent is when >the host receives AH/ESP packet with unknown SPI. And all these cases >are covered in Section 1.5 of RFC 7296 in sufficient detail, including >DoS attacks prevention measures (rate limiting). >I don't think we should repeat all this in the draft. > >> I have also moved text to section 11. Security Consideration. >> >> I=C2=B9ve added some words around the checking of the IDi/IDr. I=C2=B9ve >>personally >> seen some issues when misconfigured clients have presented an identical >> IDi, resulting in INITIAL_CONTACT deleting the =C5=92other=C2=B9 clients SA. > >Since INITIAL_CONTACT is processed after peer authentication, >malicious user cannot use it to perform DoS attack >(unless he/she is able to impersonate legitimate user, but in this case >he/she can do much worse things). And what about misconfiguration - >Section 2.4 of RFC 7296 already has all due warnings: > > This notification MUST NOT be sent by an entity that may be > replicated (e.g., a roaming user's credentials where the user is > allowed to connect to the corporate firewall from two remote systems > at the same time). > >Again, I don't think we should copy all the requirements concerning >INITIAL_CONTACT from RFC7296. GB> For this example I=E2=80=99ve personally seen misconfigured clients, this isn=E2=80=99t exactly the 'entity being replicated' (or not intentionally). As an example VPN architecture, the authentication use Digital Signatures, but send the ID as FQDN. Your laptop is provisioned with ID of FQDN=3Dvalery.example.com, mine should be FQDN=3Dgraham.example.com, however due to an IT engineer provision error I have the same ID as you in my VPN profile. When I connect, if the VPN gateway does not check the presented FQDN is in the certificate (where a mismatch would occur), I pass authentication and INITIAL_CONTACT deletes your session. The strict check of ensuring that the ID is contained within the certificate will mitigate the mis-configuration and also malicious intent. For the malicious example, it=E2=80=99s easy to spoof an ID, but it=E2=80=99s computationally impossible to spoof a certificate, hence the ID-Certificate check will mitigate any mis-conftguation or malicious intention. The behaviour of INITIAL_CONTACT is really being exploited in this case (IMO). GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, not just RFC7619, so if someone is looking to protect RFC7296 against DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but there=E2=80=99s still cases (and seem to be common) where it can happen. > >> I did think about exhaustion of IP addresses when using configuration >> payload to allocate clients IPs, if a malicious or misconfigured client >> could exhaust the pool. But I feel the wording in section 8 covers this. >> Unless others think otherwise? > >Again, allocation of IP addresses takes place after user authentication, >so it cannot be used as DoS attack by malicious user. GB> Think of mischievous users or misconfigured, as anyone who CAN pass authentication. Let me give you this example. I=E2=80=99m granted access to a VPN gateway for 24 hours, where a security policy is applied so that I only access read access to a single file. I=E2=80=99m an =E2=80=98untrusted=E2=80=99 user, this ga= teway also serves =E2=80=99trusted=E2=80=99 users. I am granted very limited access. I exhaus= t the pool of IP addresses so that no other (legitimate) users can connect. This is similar to DHCP exhaustion on a LAN. We can mitigate against that (DHCP snooping etc), I feel that we should protect IKE from a similar attack. GB> I=E2=80=99m seeing a lot of cases (IoT), where IKE is used, however the devices aren=E2=80=99t secured and are not really trusted. Examples are; Sensor o= n a pole in the middle of no-where, or unsecured in a lift shaft. For the IoT case although the authentication exchange passes, the client still isn=E2=80=99t fully trusted, so we should protect the control-plane (IKE) as best we can. GB> FWIW - I feel that the text in section 8 does sort of cover this, but wanted to describe the issue and if others feel the text doesn=E2=80=99t adequately mitigate the issue of IP address exhaustion I can add some words. >> cheers > >Regards, >Valery.=20 > --B_3541353911_2174550 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgAiuP ceR8BCyMcpv6H2bboccyPsWTQWx4n6HsROiq0FcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzIwMjEyNTExWjANBgkqhkiG9w0BAQEFAASCAQCU2DnY vY+sPgzHUJxsk8ecAR1ouxnKFXxlU3MGFT3gT2JAfKnQoCJl3ynNQ6q9Bg3vaFMDsr+E06Le HNV5qg23zOe50DERP9ryU6K7fW0EBUqWWUBnV5W1RYD5EBGzNk/e+BjVzbZBH8ZuoX2zSQ6C 4u2Ze/o551Hh2UzMpURGPT1KKhEQWrM7kJsNt21a1Mvnvb/51+Sp0VPwksilqUAujXUCcv4D UA7sJGAT4yuROQQecz2Jod6DJ9PqVf7dkvv9HdVQhGZfFTdm5JXnYTfCqpfR82me/b/GgU6H m248l+7uZrNulGlSeMR81+yUnlwfRB74Dvmv206WbK+LSu/N --B_3541353911_2174550-- From nobody Sun Mar 20 14:33:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90D012D794 for ; Sun, 20 Mar 2016 14:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 TApXAMSmA3Ze for ; Sun, 20 Mar 2016 14:33:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 8472212D505 for ; Sun, 20 Mar 2016 14:33:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qSsf24FfWz37P; Sun, 20 Mar 2016 22:33:46 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yWN_A6R-svFc; Sun, 20 Mar 2016 22:33:45 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 20 Mar 2016 22:33:45 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 850B26019B73; Sun, 20 Mar 2016 17:33:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 850B26019B73 References: <8E7A385FFC124F60A313BB202FC81979@chichi> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4EBAA701-C4E5-402B-B021-A242A91347B8@nohats.ca> X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Sun, 20 Mar 2016 17:33:32 -0400 To: "Graham Bartlett (grbartle)" Archived-At: Cc: IPsecME WG , Valery Smyslov , "Waltermire, David A. \(Fed\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 21:33:51 -0000 > On Mar 20, 2016, at 17:25, Graham Bartlett (grbartle) = wrote: >=20 > Hi Valery / Paul >=20 > Paul - does your implementation send the INFORMATIONAL + other messages > (Private Use Error) to a single SA_INIT? Just to clarify the issue > observed seemed to be SA_INIT is sent by Initiator, Responder sends an > SA_INIT reply plus numerous INFORMATIONAL messages separately to this > single SA_INIT message containing Private Use Errors. No. Only one message is sent. So no amplification is caused. >=20 > GB> I=E2=80=99ve made some comments inline for clarity. >=20 > cheers >=20 >> On 20/03/2016 06:43, "Valery Smyslov" wrote: >>=20 >> Hi Graham, >>=20 >> thank you for the updated text. >>=20 >>> I=C2=B9ve made some amendments to the proposed text based on Valerys >>> comments. >>>=20 >>> I=C2=B9ve also added text around the correct sending of INFORMATIONAL >>> messages >>> due to a Responder receiving an SA_INIT, this is a known problem today >>> with a number of implementations. (seen by Tero and myself). >>=20 >> Sorry, your text is wrong (or at least is not accurate). The responder >> must never reply to an IKE_SA_INIT with INFORMATIONAL message. >> See section 1.5 of RFC 7296: >>=20 >> In the second and third cases, the message is always sent without >> cryptographic protection (outside of an IKE SA), and includes either >> an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no >> notification data). The message is a response message, and thus it >> is sent to the IP address and port from whence it came with the same >> IKE SPIs and the Message ID and Exchange Type are copied from the >> request. The Response flag is set to 1, and the version flags are >> set in the normal fashion. >>=20 >> Note, thet Exchange Type is copied from the request, so if some >> IKE_SA_INIT >> request has unsupported major version the responder will send >> INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response. >=20 > GB> Thanks Valery - this is now clear. However not only was I confused, as= > Paul confirms there=E2=80=99s other implementations that are also confused= . Seeing > as there=E2=80=99s confusion with regards to this wording and it can lead t= o an > amplification attack I personally feel we should include the following > text for clarification? >=20 > "RFC7296 Section 1.5 describes the generating of informational messages a > Responder will send. Only a single instance of the generated message > should ever be sent for a received request and under no circumstances > should a received request cause the generation of more than a single > message in reply." I don't think mitigation text for blatant RFC errors should be added. The or= iginal error should just be fixed. If they don't comply with 7296, this docu= ment will make no difference either. >=20 >=20 >=20 >=20 >=20 >>=20 >> The only case unprotected INFORMATIONAL message is sent is when >> the host receives AH/ESP packet with unknown SPI. And all these cases >> are covered in Section 1.5 of RFC 7296 in sufficient detail, including >> DoS attacks prevention measures (rate limiting). >> I don't think we should repeat all this in the draft. >>=20 >>> I have also moved text to section 11. Security Consideration. >>>=20 >>> I=C2=B9ve added some words around the checking of the IDi/IDr. I=C2=B9ve= >>> personally >>> seen some issues when misconfigured clients have presented an identical >>> IDi, resulting in INITIAL_CONTACT deleting the =C5=92other=C2=B9 clients= SA. >>=20 >> Since INITIAL_CONTACT is processed after peer authentication, >> malicious user cannot use it to perform DoS attack >> (unless he/she is able to impersonate legitimate user, but in this case >> he/she can do much worse things). And what about misconfiguration - >> Section 2.4 of RFC 7296 already has all due warnings: >>=20 >> This notification MUST NOT be sent by an entity that may be >> replicated (e.g., a roaming user's credentials where the user is >> allowed to connect to the corporate firewall from two remote systems >> at the same time). >>=20 >> Again, I don't think we should copy all the requirements concerning >> INITIAL_CONTACT from RFC7296. >=20 >=20 >=20 > GB> For this example I=E2=80=99ve personally seen misconfigured clients, t= his > isn=E2=80=99t exactly the 'entity being replicated' (or not intentionally)= . As an > example VPN architecture, the authentication use Digital Signatures, but > send the ID as FQDN. Your laptop is provisioned with ID of > FQDN=3Dvalery.example.com, mine should be FQDN=3Dgraham.example.com, howev= er > due to an IT engineer provision error I have the same ID as you in my VPN > profile. When I connect, if the VPN gateway does not check the presented > FQDN is in the certificate (where a mismatch would occur), I pass > authentication and INITIAL_CONTACT deletes your session. The strict check > of ensuring that the ID is contained within the certificate will mitigate > the mis-configuration and also malicious intent. >=20 > For the malicious example, it=E2=80=99s easy to spoof an ID, but it=E2=80=99= s > computationally impossible to spoof a certificate, hence the > ID-Certificate check will mitigate any mis-conftguation or malicious > intention. The behaviour of INITIAL_CONTACT is really being exploited in > this case (IMO). >=20 >=20 >=20 > GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, > not just RFC7619, so if someone is looking to protect RFC7296 against > DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but > there=E2=80=99s still cases (and seem to be common) where it can happen. >=20 >=20 >=20 >>=20 >>> I did think about exhaustion of IP addresses when using configuration >>> payload to allocate clients IPs, if a malicious or misconfigured client >>> could exhaust the pool. But I feel the wording in section 8 covers this.= >>> Unless others think otherwise? >>=20 >> Again, allocation of IP addresses takes place after user authentication, >> so it cannot be used as DoS attack by malicious user. >=20 > GB> Think of mischievous users or misconfigured, as anyone who CAN pass > authentication. Let me give you this example. I=E2=80=99m granted access t= o a VPN > gateway for 24 hours, where a security policy is applied so that I only > access read access to a single file. I=E2=80=99m an =E2=80=98untrusted=E2=80= =99 user, this gateway > also serves =E2=80=99trusted=E2=80=99 users. I am granted very limited acc= ess. I exhaust > the pool of IP addresses so that no other (legitimate) users can connect. > This is similar to DHCP exhaustion on a LAN. We can mitigate against that > (DHCP snooping etc), I feel that we should protect IKE from a similar > attack. >=20 > GB> I=E2=80=99m seeing a lot of cases (IoT), where IKE is used, however th= e > devices aren=E2=80=99t secured and are not really trusted. Examples are; S= ensor on > a pole in the middle of no-where, or unsecured in a lift shaft. For the > IoT case although the authentication exchange passes, the client still > isn=E2=80=99t fully trusted, so we should protect the control-plane (IKE) a= s best > we can. >=20 > GB> FWIW - I feel that the text in section 8 does sort of cover this, but > wanted to describe the issue and if others feel the text doesn=E2=80=99t > adequately mitigate the issue of IP address exhaustion I can add some > words. >=20 >=20 >>> cheers >>=20 >> Regards, >> Valery.=20 >>=20 From nobody Sun Mar 20 14:42:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D969512D5B7 for ; Sun, 20 Mar 2016 14:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zjF7_lhGUOF4 for ; Sun, 20 Mar 2016 14:42:26 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B62612D505 for ; Sun, 20 Mar 2016 14:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5702; q=dns/txt; s=iport; t=1458510146; x=1459719746; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u6Y+/fFbflySwR7uYDrhTGU3avMtH/gfekav7O2At0Q=; b=VNeu1gzdessHqu2aLsYAaXUZLnzNJliGMwkGav8OiKmcXPGb6FvtLXVb FZCbrEtlwgkHIQrWZ9SPD++0WuLnghnrLi7HPQ4b3sgt0y9tewIEreyYz LsuUdogUAk1WFaLSxRIPzSSDFp4Ug7Qs1ZasrjEONxYl2ociG92DV0GPh o=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgBpGO9W/4MNJK1dgzOBRQa4DYIPD?= =?us-ascii?q?oFvhg0CgSA4FAEBAQEBAQFkJ4RCAQEEeRACAQhGAjAlAgQOBQ6IGb5NAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBDQiGHoREhFKFQAWXVwGDHYFmiQCBTwGNN48FAR4BQ?= =?us-ascii?q?4NlaokXfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,367,1454976000"; d="p7s'?scan'208";a="251576865" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2016 21:42:25 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2KLgPvv006294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 20 Mar 2016 21:42:25 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 20 Mar 2016 16:42:24 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Sun, 20 Mar 2016 16:42:24 -0500 From: "Graham Bartlett (grbartle)" To: Paul Wouters Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AQHRgWKQEN1mpUdbReie8Bmkunv/FZ9iOI+AgAD2dYCAAAJVAIAAAnMA Date: Sun, 20 Mar 2016 21:42:24 +0000 Message-ID: References: <8E7A385FFC124F60A313BB202FC81979@chichi> <4EBAA701-C4E5-402B-B021-A242A91347B8@nohats.ca> In-Reply-To: <4EBAA701-C4E5-402B-B021-A242A91347B8@nohats.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3541354938_2188719" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Valery Smyslov , "Waltermire, David A. \(Fed\)" , Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 21:42:28 -0000 --B_3541354938_2188719 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Paul Fair point - thanks. cheers On 20/03/2016 21:33, "Paul Wouters" wrote: > >I don't think mitigation text for blatant RFC errors should be added. The >original error should just be fixed. If they don't comply with 7296, this >document will make no difference either. --B_3541354938_2188719 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgk9si 110GZVjSoaONbEbXTSoG57rxm3n1WpOiTQSr4bcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzIwMjE0MjE4WjANBgkqhkiG9w0BAQEFAASCAQCZbksE XWlELDVQvp1QPv010c2FAyvhkZmoOFhnEoASGb6vBHPpdXgY89m2pNZAisikNuEEHW4LMKyX K+414sE12QUFwp1HjgB/wR85xhFtLdZWADXqiqImum5WAE4hJcRxR0Aq3Vc3BUutm6h4+QqC ffqc6KSk53vByV66Muuid1NK47fj1c95DOSUJ3efBE/ubU8B6wtWX01iU72hnujCq+UU8v3O /K//qxEif5q2zt+tuWOamxLNa5Di2LYq0PpYTT3I4nfMKKZ6aHWuk//A780L7jD5XzzwBxWc 5bXh0yzjPtnk2UYDQ1kUUa5fEkO8N/zD8ICCuKGxibK6I/d8 --B_3541354938_2188719-- From nobody Mon Mar 21 05:57:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653612D7DE for ; Mon, 21 Mar 2016 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c5ZhNUU7VtAV for ; Mon, 21 Mar 2016 05:57:24 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558B212D7FA for ; Mon, 21 Mar 2016 05:57:23 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id e196so31645278lfg.1 for ; Mon, 21 Mar 2016 05:57:23 -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-transfer-encoding; bh=rUjbHRz6eNC+s/XTNxTg9dYKecB6Nq7D7CmV82sXje4=; b=cd1yJPROdWDjTpJFC5SZApaHzUVkzKytpibNuHGty1+XYe+KWMEYDPYzMzTujAweLY FL9emDQb7eMONCMw1A06+0b1lAsYuci82kZ8zzf5wJn8kwHLt59pamB1faXTEGULB8sj ouxdW7oEduNeiNkB4OeGmMrOXX4EcLpFv92eN6gL7pX321grUgBezuO93QZN7VRK8D1p 2ZTiPPakSdGkiaVN5FCRbxhMohdqMmy3CyT8pe7OlHb4RXQrVL9aKR2/hpLHXiVlhlSY TQRAD7O4tbtMRe0w5gHCjKHy0gikyVoF0IgtqcexjD+7rUmDe2smS/t7mREGcsV9pXCj aVug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=rUjbHRz6eNC+s/XTNxTg9dYKecB6Nq7D7CmV82sXje4=; b=SqlMRhfJG45caq9T29gI3nw/sPbIarSe3eglUA2veMMrf4g0PIQGdMo1tcSXMKoUqE jZaZ5S53hePb0fu9DO134AZx9Mt4kfFEgigL/ZJB86splnfz87BvQUflkwFUEPSYrjz5 GBGyOGyhkX3ORCJDMngWPZvWMzIpDQj9tvyEXGmW9hzwS88VThJaQKWH1Nx1aFOl2Xu9 GGBMCfcAk/WHl1EKo02s0XNnKjPKmepefzqzXKvPs2JFplKOH89edyvcHDAC2fLAKaV1 STPiSJ+mfErZfDrK+pQsNwSQB2ZMPWR+1y1Gdqc/W+Zz8Gi9Li/GGjBdqtoSfnUoD4ey 6Zwg== X-Gm-Message-State: AD7BkJLsj9yqYpNZawAeG3kVaeLBAW0dmDIYGsDd2kNzs7g+l5TwSXB1mTJ5VWmu2zLfOA== X-Received: by 10.25.160.79 with SMTP id j76mr10980289lfe.83.1458565041488; Mon, 21 Mar 2016 05:57:21 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id sa9sm4308574lbb.38.2016.03.21.05.57.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 05:57:20 -0700 (PDT) Message-ID: <3755B9EF6414459584A2A5210E60E52C@buildpc> From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Paul Wouters" , "IPsecME WG" , "Waltermire, David A. \(Fed\)" References: <8E7A385FFC124F60A313BB202FC81979@chichi> Date: Mon, 21 Mar 2016 15:57:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit 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: Cc: Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 12:57:27 -0000 Hi Graham, > GB> Thanks Valery - this is now clear. However not only was I confused, as > Paul confirms there’s other implementations that are also confused. Seeing > as there’s confusion with regards to this wording and it can lead to an > amplification attack I personally feel we should include the following > text for clarification? > > "RFC7296 Section 1.5 describes the generating of informational messages a > Responder will send. Only a single instance of the generated message > should ever be sent for a received request and under no circumstances > should a received request cause the generation of more than a single > message in reply." Well, I don't think we should describe such obvious things. And there is already text in RFC 7296 with similar meaning in section 2.21 (however, without using imperative words): There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (such as no matching cryptographic algorithms), the response contains a Notify payload indicating the error. (Note singular "the response", not "the responses"). > >Again, I don't think we should copy all the requirements concerning > >INITIAL_CONTACT from RFC7296. > > GB> For this example I’ve personally seen misconfigured clients, this > isn’t exactly the 'entity being replicated' (or not intentionally). As an > example VPN architecture, the authentication use Digital Signatures, but > send the ID as FQDN. Your laptop is provisioned with ID of > FQDN=valery.example.com, mine should be FQDN=graham.example.com, however > due to an IT engineer provision error I have the same ID as you in my VPN > profile. When I connect, if the VPN gateway does not check the presented > FQDN is in the certificate (where a mismatch would occur), I pass > authentication and INITIAL_CONTACT deletes your session. The strict check > of ensuring that the ID is contained within the certificate will mitigate > the mis-configuration and also malicious intent. I don't think we are in a position to impose such a requirement in the draft. RFC 7296 doesn't have a requirement that an ID must be present in the certificate. Moreover, Section 3.5. explicitely allows ID be different from any field in certfificate: The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. There are many good reasons not to to impose such a requirement - there are many use cases when ID payload just cannot be directly mapped to credentials (preshared keys, some EAP methods, raw public keys etc.), so the mapping is performed via Local Policy. It allows more flexibility in real life, but at the same time it requires Local Policy to be written with care. In your example there is a clear configuration error, and I don't think we could do anything about this on RFC level. Next time IT engineer issues two certificates with equal FQDNs to two different people and the situation you described happens again, even if SGW will check the match betweed ID and certificate... > For the malicious example, it’s easy to spoof an ID, but it’s > computationally impossible to spoof a certificate, hence the > ID-Certificate check will mitigate any mis-conftguation or malicious > intention. The behaviour of INITIAL_CONTACT is really being exploited in > this case (IMO). No, I don't think so. To exploit this mis-configuration a malicious user must be authenticated by SGW. So, he/she is not an unknown attacker, he/she does have proper credentials. In this case he/she can be traced down and the out-of-band measures can be taken. > GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, > not just RFC7619, so if someone is looking to protect RFC7296 against > DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but > there’s still cases (and seem to be common) where it can happen. The draft has a reference to RFC7619. In general, NULL auth is not relevant to DoS protection unless your product supports it. And in this case you have to read RFC 7619 anyway while adding support, right? > >Again, allocation of IP addresses takes place after user authentication, > >so it cannot be used as DoS attack by malicious user. > > GB> Think of mischievous users or misconfigured, as anyone who CAN pass > authentication. Let me give you this example. I’m granted access to a VPN > gateway for 24 hours, where a security policy is applied so that I only > access read access to a single file. I’m an ‘untrusted’ user, this gateway > also serves ’trusted’ users. I am granted very limited access. I exhaust > the pool of IP addresses so that no other (legitimate) users can connect. > This is similar to DHCP exhaustion on a LAN. We can mitigate against that > (DHCP snooping etc), I feel that we should protect IKE from a similar > attack. > > GB> I’m seeing a lot of cases (IoT), where IKE is used, however the > devices aren’t secured and are not really trusted. Examples are; Sensor on > a pole in the middle of no-where, or unsecured in a lift shaft. For the > IoT case although the authentication exchange passes, the client still > isn’t fully trusted, so we should protect the control-plane (IKE) as best > we can. > > GB> FWIW - I feel that the text in section 8 does sort of cover this, but > wanted to describe the issue and if others feel the text doesn’t > adequately mitigate the issue of IP address exhaustion I can add some > words. Could you please describe how you exhaust the pool of IP addresses? If you are authenticated user you'll receive the same IP address no matter how many times you ask for it (in general it depends on SGW implementation, I assume SGW links client ID with IP from poll). If you use NULL auth, then it is a different story, but I think RFC 7619 describes the risks of using NULL auth. Regards, Valery. From nobody Mon Mar 21 08:55:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3612D8CB for ; Mon, 21 Mar 2016 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LAeoFO4cIeP1 for ; Mon, 21 Mar 2016 08:54:59 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B951912D8E1 for ; Mon, 21 Mar 2016 08:54:36 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id oe12so129297022lbc.0 for ; Mon, 21 Mar 2016 08:54:36 -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; bh=Zr4a4qDpIDUNEJrtrJayK6b4WD9ByaqDSb99pNDV08c=; b=Vx7rhnHlCTi93S4KkhQq/ijdRHMa6aNmla7A2DUbh2VQB/+XRzFbib/y8VOfYWLQnE VXGzdwJsjHKmPU6ALjbrGZcvw8gHILsNmusnH9JTPcrBF7/djLSc9FDPv+dy+UT6AIkI 0KZhEw4pjFZHFNlDEiIOcGgadRkltXYCmC5v/GXh1y/A0HXpqM8OAttJ4+Qtbd0j7nlC oEt2hReD/+W7ncXg53uXfD1rdS7YJeIDFVRVj0XP/wSxOf9kGFmCxRHRC3D+Tqfe/Giq 4JTnBOj8fPmcZSRE0pqapEVTdt1IpOmpZ5WCsWIh165+uTXaUevjbm9lwJ/hqQ6CdkRh sAyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Zr4a4qDpIDUNEJrtrJayK6b4WD9ByaqDSb99pNDV08c=; b=c5cwSewfQF50n38tVIbZE42CCaDvGjtElEOj4RIp2PT9vtCqSnG2JarKZ9cXD5I62A vPX/Fwy+CFxXbaxsgMZzg9dtnN5xNyz6PRTHgEiemVE/16g9S9EjQR4hNVofP1bir7jH UhQRKwB6TY9SbK5+UfvZZQlSOqLR6I8POPgcQvbiV2aU7bQ+FWWMq6Wq4qAPtcg86aKm yU0E8Dcv8xUXRO83Wfom7Wkok6xIG2ru9/q2i2thNUhxFVLMCPstOjOUSelrwpSrYVmi 9CfxiaOeM8ETemDCE8MNV4QPT2G0PDBqD3ljlliB2n8AmYVSrcB6jLGruBFBj0CnnQzT NNXg== X-Gm-Message-State: AD7BkJLTtBkcOOtS20+n15r98h/tu4hrap0Tc9rH4QQiFO70SqGGZQW8PpiaViRAAroRUYGlsxXJKZ6ZOnTcTw== MIME-Version: 1.0 X-Received: by 10.112.235.71 with SMTP id uk7mr10963714lbc.39.1458575674979; Mon, 21 Mar 2016 08:54:34 -0700 (PDT) Received: by 10.25.29.141 with HTTP; Mon, 21 Mar 2016 08:54:34 -0700 (PDT) In-Reply-To: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> Date: Mon, 21 Mar 2016 16:54:34 +0100 Message-ID: From: Daniel Palomares To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c3c5c2fc3ae9052e911c52 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:55:02 -0000 --001a11c3c5c2fc3ae9052e911c52 Content-Type: text/plain; charset=UTF-8 Hello Paul, MOBIKEv2 was already presented in IETF90. https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-3.pdf We had little discussion, but I felt there was interest on this proposal. Actually what MOBIKEv2 proposes, is to change the IP used in the IKE Security Association without having to renegotiate the whole set of keys again. As transport mode addresses endpoint-to-endpoint communications, the most suitable scenarios are any-to-any networks willing to communicate using IPsec. https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-2.pdf Regards Daniel 2016-03-14 11:45 GMT+01:00 Paul Wouters : > On Mon, 14 Mar 2016, Daniel Palomares wrote: > > I would like to propose MOBIKEv2 as part of the charter. >> >> What it basically proposes is to add MOBIKE support for Transport Mode >> (and not only tunnel mode). The most suitable scenarios that would >> benefit from this are any-to-any networks implementing IPsec in transport >> mode. >> > > I dont even understand how that would work in transport mode, but I'm > not a MOBIKE expert. > > Probably best to discuss this in the working group, then when the > workgring group sees this as something to work on, we could add it to > the charter? > > Paul > --001a11c3c5c2fc3ae9052e911c52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually what MOBIKEv2 proposes, is to change the IP used in the IKE Security=20 Association without having to renegotiate the whole set of keys again.=20 As transport mode addresses endpoint-to-endpoint communications, the=20 most suitable scenarios are any-to-any networks willing to communicate=20 using IPsec.
https://www.ietf.org/proceedings/90/slides/slides-90-ip= secme-2.pdf

Regards
Daniel


2016-03-14 11:45 GMT+01:00= Paul Wouters <paul@nohats.ca>:
On Mon, 14 Mar 2016, Daniel Palomares wrote:

I would like to propose MOBIKEv2 as part of the charter.

What it basically proposes is to add MOBIKE support for Transport Mode (and= not only tunnel mode). The most suitable scenarios that would
benefit from this are any-to-any networks implementing IPsec in transport m= ode.

 I dont even understand how that would work in transport mode, but I'm not a MOBIKE expert.

Probably best to discuss this in the working group, then when the
workgring group sees this as something to work on, we could add it to
the charter?

Paul

--001a11c3c5c2fc3ae9052e911c52-- From nobody Mon Mar 21 10:58:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0D512D9BD for ; Mon, 21 Mar 2016 10:58:17 -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 autolearn_force=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 3XHePLiEzOqb for ; Mon, 21 Mar 2016 10:58:16 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 7496412D9CB for ; Mon, 21 Mar 2016 10:58:12 -0700 (PDT) Received: from [10.32.60.126] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2LHw8gw027945 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 10:58:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.126] From: "Paul Hoffman" To: "Daniel Palomares" Date: Mon, 21 Mar 2016 10:58:08 -0700 Message-ID: <83D3AEAF-324E-46BF-808E-D2DF387B7559@vpnc.org> In-Reply-To: References: <82BDFE1B-EF80-49EA-BD47-4D77C5E812EA@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Proposed wording for a revised charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:58:17 -0000 On 21 Mar 2016, at 8:54, Daniel Palomares wrote: > Hello Paul, > > MOBIKEv2 was already presented in IETF90. > https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-3.pdf > We had little discussion, but I felt there was interest on this > proposal. I understand that it was discussed in the distant past, and that there was a tad of interest. That's not enough to get it in the charter. --Paul Hoffman From nobody Mon Mar 21 13:13:28 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3512912D656; Mon, 21 Mar 2016 13:13:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 13:13:28 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:13:28 -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 of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-05.txt Pages : 29 Date : 2016-03-21 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-05 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 Mar 21 18:05:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C706412D149 for ; Mon, 21 Mar 2016 18:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=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 UOlsc_1KR2Rw for ; Mon, 21 Mar 2016 18:05:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3E38612D147 for ; Mon, 21 Mar 2016 18:05:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qTZHb3hyBz37S for ; Tue, 22 Mar 2016 02:05:15 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8Je7SXnar1VO for ; Tue, 22 Mar 2016 02:05:13 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 22 Mar 2016 02:05:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C72C46019B73; Mon, 21 Mar 2016 21:05:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca C72C46019B73 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C1DD118D79 for ; Mon, 21 Mar 2016 21:05:11 -0400 (EDT) Date: Mon, 21 Mar 2016 21:05:11 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> Message-ID: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 01:05:19 -0000 On Mon, 21 Mar 2016, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-05 I would remove most of the speculative text in: In IPv4 it makes sense to limit the number of half-open SAs based on IP address. Most IPv4 nodes are either directly attached to the Internet using a routable address or are hidden behind a NAT device with a single IPv4 external address. IPv6 networks are currently a rarity, so we can only speculate on what their wide deployment will be like, but the current thinking is that ISP customers will be assigned whole subnets, so we don't expect the kind of NAT deployment that is common in IPv4. For this reason, it makes sense to use a 64-bit prefix as the basis for rate limiting in IPv6. And replace it with: For IPv6, ISPs assign either a /48 or /64, so it makes sense to use a 64-bit prefix as the basis for rate limiting in IPv6. I'm not sure about: The number of half-open SAs is easy to measure, but it is also worthwhile to measure the number of failed IKE_AUTH exchanges. If possible, both factors should be taken into account when deciding which IP address or prefix is considered suspicious. I'm not sure what measuring the failed IKE_AUTH exchanges gains you? Whether or not you accept new work should more depend on your own resoures than previously failed attempts, otherwise you risk becoming a victim of lock-out attacks where an attacker causes so many failures that legitimate clients would be prevented from initiating IKE. Especially with CGNAT. Next item: There are two ways to rate-limit a peer address or prefix: 1. Hard Limit - where the number of half-open SAs is capped, and any further IKE_SA_INIT requests are rejected. 2. Soft Limit - where if a set number of half-open SAs exist for a particular address or prefix, any IKE_SA_INIT request will require solving a puzzle. This does not mention the build-in defense of the DCOOKIE defense from the base IKEv2 spec. Although it does shortly after: The cookie mechanism limits the amount of allocated state to the size of the bot-net, multiplied by the number of half- open SAs allowed per peer address, multiplied by the amount of state allocated for each half-open SA. With typical values this can easily reach hundreds of megabytes. It would be clearer to to mention explicitely that the cookie mechanism prevents spoofed packets from taking up state, thereby limiting [....] Note that the Responder SHOULD cache tickets for a short time to reject reused tickets (Section 4.3.1), and therefore there should be no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME messages. I should probably read 5723, but why would one ever respond to an "old" re-used or unknown session resume ticket? I guess the only use is a faster failure of lost resumption tickets for real clients? Since just sending a "go away" response is not more computationally expensive then creating a "go away" response for an invalid IKE SPI or badly formed IKE packet, I would say it is not worth implementing a separate list of recently used tickets. If the received IKE_AUTH message failed to decrypt correctly (or failed to pass ICV check), then the Responder SHOULD still keep the computed SK_* keys, so that if it happened to be an attack, then the malicious Initiator cannot get advantage of repeating the attack multiple times on a single IKE SA. Well, it needs to do this anyway in case the attacker is just sending bogus responses faster than the real client. So I don't think this advise here is warranted - it has nothing to do with ddos. To prevent this kind of attacks the responder should not blindly download the whole file. Instead it SHOULD first read the initial few bytes, decode the length of the ASN.1 structure from these bytes, and then download no more than the decoded number of bytes. That seems really bad. If the attacker controls the URL, they can also put an malicious ASN.1 encoding in the cert. Much better is to [Oh never mind you write all the things I wrote here already] With a typical setup and typical Child SA lifetimes, there are typically no more than a few such exchanges, often less. I don't agree. People put in 1s liveness probes, so that's a lot of IKE packets. Since any endpoint can initiate a new exchange, [...] I would more explicitely point the AUTH NULL based attacks to its RFC. Then focus this document on the possible abuse of legitimate clients. However, I don't know what I would want to advise. You can put in maximums for rekeys, reauths, or child sa's, but those should at most be configuration options, and not hardcoded options in the implementation - since implementors cannot predict what legitimate large scale use their code might see. For that reason, it is NOT RECOMMENDED to ever increase the IKEv2 window size above its default value of one if the peer uses NULL Authentication. I'm not sure why here the auth method is used to discriminate. Earlier it also talked about authenticated clients and launching many exchanges? Also, this advise is actually an update to RFC7619/RFC7296 so this document should list it is updating those RFC's. If the peer initiates too many exchanges of any kind, implementations can introduce an artificial delay before responding to request messages. This delay would decrease the rate the implementation need to process requests from any particular peer, making it possible to process requests from the others. The delay should not be too long to avoid causing the IKE SA to be deleted on the other end due to timeout. I am not sure how useful this advise is. Since people use liveness timeouts of 1s, a malicious peer can always do 1s of exchanges. So if you want to introduce delays, they should probably delay only non-liveness exchanges. And liveness exchanges that are more frequent that 1s should probably just be dropped or rejected. Note, that if the Responder receives retransmissions of the request message during the delay period, the retransmitted messages should be silently discarded. That also updated RFC-7296 which states that each IKE request should get an IKE answer. And these should be very cheap to send anyway. At least our implementation caches the last sent IKE packet for retransmissions. While the document mentions Fragmentation with respect to puzzles, it does not mention ddos attacks based on malicious fragmentation packets. It could be that the base RFC is clear enough, but perhaps this document should give some advise too? Paul From nobody Tue Mar 22 01:43:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEBD12D7F1 for ; Tue, 22 Mar 2016 01:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gx4E_vHwF2zB for ; Tue, 22 Mar 2016 01:43:52 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D2E12D7EC for ; Tue, 22 Mar 2016 01:43:51 -0700 (PDT) Received: by mail-lb0-x232.google.com with SMTP id oe12so151628440lbc.0 for ; Tue, 22 Mar 2016 01:43:51 -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-transfer-encoding; bh=0q6KJhj51shDbQnE/ac3TfW/rCSd7fZ3zVjV94n3OZ8=; b=LSaXz/u0DHQRlKQZ7gE+wZoNwOwljnIIyvgdQa/H6rgY5XzauCQeiHW/hRIxuah/W/ FBahfuFqecIriuP15tzPhW7h6qZbD8Ps5eJMqTzd5bj+iIKVgoV2fhXBepP54x870gCC t8mJe1onOEXlH3LhoyToGN6pNoEKiz2uy8gtlGlRi7l5UOdb2DRQ6DD6wv4poCT/MTl1 0mpGiCsz2LBp/PONQkc0Q0OZi0c2ui9DnFwff3Od5Bc+6BJNSLpoBFesVId9DH7hYVaB s3jSK1HUf09hS3NcMcwl9GWi2IwU9gNS+ccd9vgnRn9B41G0o1me00fDXTk3EClHs2GI PirQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=0q6KJhj51shDbQnE/ac3TfW/rCSd7fZ3zVjV94n3OZ8=; b=cBvTea3NsvEH06ZMvb/LQquv/dsHk0Gr1oCX4w0mBe5KYc2I+dmjaWmVJrVmm+tTjU HoqFgfKAm8rhCY7LgUfjd34B9hqZq8vV0MN+Y5KT4rBhtOwVL89/3LHdQcjUQAHU2i3M QIGtzYx1++te87+3fqoMmr6ERx9n4EjFbxAV2CLh/XgCDcv5fIbrlqBPPijqk2wTmMhY NFuOua3pmdyv0InIAWG34mFv+MMNjBU1QJ2WHQePXqf9L/lkZehqVp9m4gTSD+X0ci4s AVbVKmH52cW9OQ+axh5ZIFE9/MMsoXkPEelO+JWcmogl4SQARPZzKDLq6hBkQsLoK7Bv UWoA== X-Gm-Message-State: AD7BkJKL9B5oNztF00pFIQZCAiC64cQfh6DG3KRySmiMMzR1GPuXlNwoz62AtY1anre+FA== X-Received: by 10.25.19.151 with SMTP id 23mr13730408lft.126.1458636229430; Tue, 22 Mar 2016 01:43:49 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id zv6sm5109384lbb.14.2016.03.22.01.43.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 01:43:48 -0700 (PDT) Message-ID: <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> From: "Valery Smyslov" To: "Paul Wouters" , References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 11:43:58 +0300 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: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 08:43:54 -0000 Hi Paul, thank you for the detailed review. > I would remove most of the speculative text in: > > In IPv4 it makes sense to limit the number of half-open SAs based on > IP address. Most IPv4 nodes are either directly attached to the > Internet using a routable address or are hidden behind a NAT device > with a single IPv4 external address. IPv6 networks are currently a > rarity, so we can only speculate on what their wide deployment will > be like, but the current thinking is that ISP customers will be > assigned whole subnets, so we don't expect the kind of NAT deployment > that is common in IPv4. For this reason, it makes sense to use a > 64-bit prefix as the basis for rate limiting in IPv6. > > And replace it with: > > For IPv6, ISPs assign either a /48 or /64, so it makes sense to > use a 64-bit prefix as the basis for rate limiting in IPv6. Do I get you right that you want to remove the following text? IPv6 networks are currently a rarity, so we can only speculate on what their wide deployment will be like, but the current thinking is that ISP customers will be assigned whole subnets, so we don't expect the kind of NAT deployment that is common in IPv4. > I'm not sure about: > > The number of half-open SAs is easy to measure, but it is also > worthwhile to measure the number of failed IKE_AUTH exchanges. If > possible, both factors should be taken into account when deciding > which IP address or prefix is considered suspicious. > > I'm not sure what measuring the failed IKE_AUTH exchanges gains you? It allows a responder to make a decision whether it is under attack. If a percentage of IKE_AUTH exchanges that failed to decrypt properly is high enough, then it means that a large fraction of initiators send bogus IKE_AUTH requests, so the responder can assume that they do this for reason. In this case the responder can use puzzles in IKE_AUTH (see Section 7.2). > Whether or not you accept new work should more depend on your own > resoures than previously failed attempts, otherwise you risk becoming a It is based on both. You must maintain some statistics information (number of half-open IKE_SA_INIT, number of failed IKE_AUTH) and make a decision whether to use defensive measures by analyzing this statistics. If you only take into consideration your resources consumption, then you would end up punishing legitimate clients in case there are so many of them that you just cannot handle the volume of requests, even if there are no no orphaned IKE_SA_INIT or failed IKE_AUTH. In other words, you must distinguish attack from just a high load. Statistics helps you in this case. > victim of lock-out attacks where an attacker causes so many failures > that legitimate clients would be prevented from initiating IKE. > Especially with CGNAT. See above. Once you make a decision that an attak is in progress (e.g. by monitoring the number of failed IKE_AUTH within last N seconds), you'll turn on IKE_AUTH puzzles or take some other measures. > Next item: > > There are two ways to rate-limit a peer address or prefix: > > 1. Hard Limit - where the number of half-open SAs is capped, and any > further IKE_SA_INIT requests are rejected. > > 2. Soft Limit - where if a set number of half-open SAs exist for a > particular address or prefix, any IKE_SA_INIT request will > require solving a puzzle. > > This does not mention the build-in defense of the DCOOKIE defense from > the base IKEv2 spec. Although it does shortly after: Cookies are described in the next chapter. > The cookie mechanism limits the amount of allocated > state to the size of the bot-net, multiplied by the number of half- > open SAs allowed per peer address, multiplied by the amount of state > allocated for each half-open SA. With typical values this can easily > reach hundreds of megabytes. > > It would be clearer to to mention explicitely that the cookie mechanism > prevents spoofed packets from taking up state, thereby limiting [....] Could you please be more explicit what text you are not happy with? > Note that the Responder SHOULD cache > tickets for a short time to reject reused tickets (Section 4.3.1), > and therefore there should be no issue of half-open SAs resulting > from replayed IKE_SESSION_RESUME messages. > > I should probably read 5723, but why would one ever respond to an "old" > re-used or unknown session resume ticket? I guess the only use is a > faster failure of lost resumption tickets for real clients? Since just > sending a "go away" response is not more computationally expensive then > creating a "go away" response for an invalid IKE SPI or badly formed IKE > packet, I would say it is not worth implementing a separate list of > recently used tickets. RFC 5723 describes two kinds of tickets - "ticket by reference" and "ticket by value". In the former case the server stores all the information regarding IKE SAs that can be resumed and the ticket is just an "index" in that database. With this approach the server always knows whether the ticket was already used or not. With the latter approach all the information regarding the SA is stored in the ticket itself. The server stores nothing in this case - it just decrypts the presented ticket and resumes the IKE SA. In this case the server doesn't know whether the ticket is used before unless it maintaines a cache of recently used tickets. > If the received IKE_AUTH message failed to decrypt correctly (or > failed to pass ICV check), then the Responder SHOULD still keep the > computed SK_* keys, so that if it happened to be an attack, then the > malicious Initiator cannot get advantage of repeating the attack > multiple times on a single IKE SA. > > Well, it needs to do this anyway in case the attacker is just sending > bogus responses faster than the real client. So I don't think this Do you mean "bogus requests"? Isn't it a DoS attack? > advise here is warranted - it has nothing to do with ddos. I think this advise is closely related to DoS protection. You yourself described the attack two lines above. > To prevent this kind of attacks the responder should not blindly > download the whole file. Instead it SHOULD first read the initial > few bytes, decode the length of the ASN.1 structure from these bytes, > and then download no more than the decoded number of bytes. > > That seems really bad. If the attacker controls the URL, they can also > put an malicious ASN.1 encoding in the cert. Much better is to [Oh never > mind you write all the things I wrote here already] OK. > With a typical setup and typical Child SA lifetimes, there > are typically no more than a few such exchanges, often less. > > I don't agree. People put in 1s liveness probes, so that's a lot of IKE > packets. Liveness check is about 50 bytes. Even if it is performed every second, it results in 2 packet/sec and 100 bytes/sec traffic per a client. Is it a lot? > Since any endpoint can initiate a new exchange, [...] > > I would more explicitely point the AUTH NULL based attacks to its RFC. Well, I think we tryed to follow this way: there is little specific to NULL auth, it is just mentioned (and referenced) as one of the factors that may make DoS attacks more easy to mount. > Then focus this document on the possible abuse of legitimate clients. > However, I don't know what I would want to advise. You can put in > maximums for rekeys, reauths, or child sa's, but those should at most > be configuration options, and not hardcoded options in the > implementation - since implementors cannot predict what legitimate > large scale use their code might see. Sure. And that's why the draft doesn't prescribe any hard limits, it just lists possible defense measures. > For that reason, it is NOT RECOMMENDED to > ever increase the IKEv2 window size above its default value of one > if the peer uses NULL Authentication. > > I'm not sure why here the auth method is used to discriminate. Earlier > it also talked about authenticated clients and launching many exchanges? Because with NULL auth the peer is not authenticated and we'd rather limit him/her abilities to mount DoS attack by initiating N exchanges in parallel, that would increase our peak load. If the peer is authenticated, then launching N exchanges simultaneously is not an attack in general. And if the authenticated peer mounts such a DoS attack, the he/she could be traced down and either out-of-band measures are taken or peer's credentials are revoked. > Also, this advise is actually an update to RFC7619/RFC7296 so this > document should list it is updating those RFC's. Is it really needed? RFC 7296 doesn't deal with NULL auth, and RFC 7619 does reference this draft in Security Considerations. What others think of it? > If the peer initiates too many exchanges of any kind, > implementations can introduce an artificial delay before > responding to request messages. This delay would decrease the > rate the implementation need to process requests from any > particular peer, making it possible to process requests from the > others. The delay should not be too long to avoid causing the IKE > SA to be deleted on the other end due to timeout. > > I am not sure how useful this advise is. Since people use liveness > timeouts of 1s, a malicious peer can always do 1s of exchanges. So if > you want to introduce delays, they should probably delay only > non-liveness exchanges. And liveness exchanges that are more frequent > that 1s should probably just be dropped or rejected. It doesn't matter what exchange type is. The intention is to artificially limit the number of exchanges the malicious peer can initiate per second. There is a MID window, so the peer cannot initiate a new exchange until one of the currently active exchanges is completed. If, for example, window size is 1, then the malcious peer cannot initiate a new exchange until we send a responce to the current one. If we send response immediately, then the malicious peer immediately initiates another exchange. If we respond in 3 seconds, then it will have to wait 3 seconds, before it can initiate a new exchange (probably sending retransmissions during that time that we will ignore). That's an idea. If malicious peer is so impatient, that it'll tear down the IKE SA if no response is received within 3 seconds, then it'll make worse for itself - it'll need to create a new IKE SA from scratch passing all the puzzles barriers. > Note, that if the Responder > receives retransmissions of the request message during the delay > period, the retransmitted messages should be silently discarded. > > That also updated RFC-7296 which states that each IKE request should get > an IKE answer. I don't think artificaial delay is a violation of RFC 7296. Each IKE request will be answered. RFC 7296 doesn't require that it is answered immediately (or as soon as responder can prepare the response). > And these should be very cheap to send anyway. At least > our implementation caches the last sent IKE packet for retransmissions. Yes, you can count the number of received retransmissions during the artificial delay and once the delay is over send back that number of identical responses at once. It is cheap. However I'm not sure it makes sense. > While the document mentions Fragmentation with respect to puzzles, it > does not mention ddos attacks based on malicious fragmentation packets. > It could be that the base RFC is clear enough, but perhaps this document > should give some advise too? I think RFC 7383 lists possible DoS attacks in Security Considerations section. Do you think it's not enough? > Paul Regards, Valery. From nobody Tue Mar 22 06:42:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330DD12D77A for ; Tue, 22 Mar 2016 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 LwjmGQVlDIOi for ; Tue, 22 Mar 2016 06:42:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 7239312D5E9 for ; Tue, 22 Mar 2016 06:42:07 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2MDfuve004198 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 15:41:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2MDft0X017393; Tue, 22 Mar 2016 15:41:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22257.19363.435510.89554@fireball.acr.fi> Date: Tue, 22 Mar 2016 15:41:55 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <3755B9EF6414459584A2A5210E60E52C@buildpc> References: <8E7A385FFC124F60A313BB202FC81979@chichi> <3755B9EF6414459584A2A5210E60E52C@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 24 min Archived-At: Cc: IPsecME WG , Paul Wouters , "Graham Bartlett \(grbartle\)" , Yoav Nir , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 13:42:19 -0000 Valery Smyslov writes: > Well, I don't think we should describe such obvious things. > And there is already text in RFC 7296 with similar meaning > in section 2.21 (however, without using imperative words): > > There are many kinds of errors that can occur during IKE processing. > The general rule is that if a request is received that is badly > formatted, or unacceptable for reasons of policy (such as no matching > cryptographic algorithms), the response contains a Notify payload > indicating the error. > > (Note singular "the response", not "the responses"). This is true when sending a response. This is not the case we are talking about. This implementation will start completely new INFORMATIONAL exchange after the IKE_SA_INIT times out. I.e., attacker sends IKE_SA_INIT request, server responds to this, and then nothing comes through later. Then the responder will time out the IKE_SA_INIT because it is half open IKE SA, and starts to do something on it. In one case we have seen responder initiating completely new INFORMATIONAL exchange with private error code inside. I.e., this was not a response, it was new request with new message id etc, and this request was then retransmitted as RFC7296 specifies for several times, before it timed out. This exchange was completely in clear as the IKE SA was not yet finished. In another case the responder again started new INFORMATIONAL exchange, but in this the original responder sent encrypted delete payload for the half open IKE SA, and this message was retransmitted only once, i.e. only two packets were sent. The original initiator receiving encrypted and MACed delete notification for IKE SA it is trying to negotiate (lets say the IKE_AUTH never reached the responder as they were so big that IP layer fragmented them and then some network device dropped them) will know that this is from the node it has talked to in IKE_SA_INIT, so there is no reason not to act on that delete. Both of those were using new exchanges, which means they were NOT against the RFC7296, but especially the first one sending 20+ retries for the private error notification message was causing amplification factor. The second case is actually quite good compromize to recover from cases where some extraordinary case might cause half open IKE SA to be formed and not causing real amplification for attackers. Anyways I think the first case is clearly a implementation misfeature, and they should fix it. The second case is implementation feature, which might be usable in certain environments. And they might have rate limiters on it. > In your example there is a clear configuration error, and I don't think > we could do anything about this on RFC level. Yes. We do not need to try to cover configuration errors and their effect on DDoS. > Could you please describe how you exhaust the pool of IP addresses? > If you are authenticated user you'll receive the same IP address no matter > how many times you ask for it (in general it depends on SGW implementation, > I assume SGW links client ID with IP from poll). I was about to point exactly that. > If you use NULL auth, then it is a different story, but I think > RFC 7619 describes the risks of using NULL auth. Of course if you are giving address to NULL auth clients then the situation might be different, but 10.0.0.0/8 network has quite a lot of addresses you can give out, before you exhaust the pool. -- kivinen@iki.fi From nobody Tue Mar 22 06:49:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F7612D7E6 for ; Tue, 22 Mar 2016 06:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 74yWCQUp0LkD for ; Tue, 22 Mar 2016 06:49:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 31BE712D838 for ; Tue, 22 Mar 2016 06:49:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2MDnacL011707 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 15:49:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2MDnZCr005718; Tue, 22 Mar 2016 15:49:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22257.19823.718120.641684@fireball.acr.fi> Date: Tue, 22 Mar 2016 15:49:35 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 13:49:42 -0000 Paul Wouters writes: > If the peer initiates too many exchanges of any kind, > implementations can introduce an artificial delay before > responding to request messages. This delay would decrease the > rate the implementation need to process requests from any > particular peer, making it possible to process requests from the > others. The delay should not be too long to avoid causing the IKE > SA to be deleted on the other end due to timeout. > > I am not sure how useful this advise is. Since people use liveness > timeouts of 1s, a malicious peer can always do 1s of exchanges. So if > you want to introduce delays, they should probably delay only > non-liveness exchanges. And liveness exchanges that are more frequent > that 1s should probably just be dropped or rejected. If someone is stupid enough to allow anybody to configure liveness timeout of 1 seconds, he gets what he deserves. In normal case having more than 10 exchanges per minute is too much, unless you are using per port SAs or similar special cases. Also having liveness checks more often than 30 seconds should be penalized, especially if implementation is using broken periodic liveness checks. It is fine to have 10 second liveness check timeout for one way traffic, i.e., when the traffic changes to be one-way you ONCE do liveness check after 10 seconds, but then you do NOT do liveness check again until something else happens. It will still take several minutes to notice that the liveness check failed, so there is no point of doing them too often. -- kivinen@iki.fi From nobody Tue Mar 22 07:01:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F9612D7FE for ; Tue, 22 Mar 2016 07:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 xG-tluxR9CtC for ; Tue, 22 Mar 2016 07:01:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5042A12D808 for ; Tue, 22 Mar 2016 07:01:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2ME1Ucn026630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 16:01:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2ME1UGt001856; Tue, 22 Mar 2016 16:01:30 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22257.20538.194024.501176@fireball.acr.fi> Date: Tue, 22 Mar 2016 16:01:30 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:01:40 -0000 Valery Smyslov writes: > > With a typical setup and typical Child SA lifetimes, there > > are typically no more than a few such exchanges, often less. > > > > I don't agree. People put in 1s liveness probes, so that's a lot of IKE > > packets. > > Liveness check is about 50 bytes. Even if it is performed every > second, it results in 2 packet/sec and 100 bytes/sec traffic per a > client. Is it a lot? When you pay for all your mobile traffic for 0.62 eur/MB (my roaming charges in Hong Kong) that will 8 eur/day. And I am sure there are better use for the bandwidth than sending liveness checks. > If we respond in 3 seconds, then it will have to wait 3 seconds, > before it can initiate a new exchange (probably sending > retransmissions during that time that we will ignore). That's an > idea. If malicious peer is so impatient, that it'll tear down the > IKE SA if no response is received within 3 seconds, then it'll make > worse for itself - it'll need to create a new IKE SA from scratch > passing all the puzzles barriers. And RFC7296 do suggest that you try for several minutes before you time out: The number of retries and length of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. > > Note, that if the Responder > > receives retransmissions of the request message during the delay > > period, the retransmitted messages should be silently discarded. > > > > That also updated RFC-7296 which states that each IKE request should get > > an IKE answer. > > I don't think artificaial delay is a violation of RFC 7296. Each IKE > request will be answered. RFC 7296 doesn't require that it is > answered immediately (or as soon as responder can prepare the > response). That is true. Having delay before responding to the request is completely legal and is perfect way to make sure nobody uses stupid settings like 1 second liveness delay. If you detect such setting it might be good idea to put 60 second delay for liveness check that come more often than once per minute... -- kivinen@iki.fi From nobody Tue Mar 22 07:32:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D7112D831 for ; Tue, 22 Mar 2016 07:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fgOCKkaQM-eR for ; Tue, 22 Mar 2016 07:32:14 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C365312D813 for ; Tue, 22 Mar 2016 07:32:13 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id bc4so164536143lbc.2 for ; Tue, 22 Mar 2016 07:32:13 -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-transfer-encoding; bh=hzLiSugJ0sjYD1UQjsDEneXPrXaVm648uAy8FJUGmsU=; b=yAJcPzHkDiC6HSB81RWA7Yj2uv3XUlwgSa/4xTSJJACnz6L3XjN8Qzy+lSHR0WBQ7/ exjFyLq85UkGA+oEPPEZz1VRyu6PcC98WaeNzDs86rdMkF5JY1WowWUbfDQyCCovWJa+ +0fgEhqy8aiopNZh5zB4Fb913tMEB8jmlR5kJWEFpO5au+0W2ZtIcJNbJ+c2kJLCOe8+ UK6SMAieXy4+soVEt1jpyQMVevfK2L/mA4urgFLCF5r3IZBbTpBEb1jhjtQnPkh93zbE Si4yZ3kUfSw8HqYnm6xIsds42qUuk/kNEpyaHCUzjguhv41X7s81ogUF9OwGCCL4iUyU Axhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=hzLiSugJ0sjYD1UQjsDEneXPrXaVm648uAy8FJUGmsU=; b=CjMZOuakLfheqAY9PRsjvcayHp+aLKj3ORnetfquLALgDOqsOrsitYQ0cK/wS/mAna BuxumeMVVCkYPWcMjz0WGJRVkZLvB708C/RSXySLBoy2VaGdfWa+1DHeZPpHI2NBBaQZ ky59awhbe2f46o9Vm2Pv0yoPm3GYiAaed/fNJWz+l4c6kBx6jCl43o/VJhOfZaA22Kpd azbRyB+0UUmfgeF3y2BtlZC3PTNhBFBLdEThNgicRejhlPpiS/kqaxW8bgydSZOacbsi IwfUuc8yhj2oABf1raCwPVIMb40wWqGM2nTdu8p1yQzwsyPYW4CcPdSJfguSId+8FJ1Z yMog== X-Gm-Message-State: AD7BkJItJWwP+Fi2di3yYJ9TTvHcHJbKSVXvs8Ibc4k/0OH1lLgOQsl89DK0uknz6YS9aw== X-Received: by 10.25.0.194 with SMTP id 185mr13605498lfa.4.1458657131917; Tue, 22 Mar 2016 07:32:11 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id jb5sm5224963lbc.8.2016.03.22.07.32.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 07:32:11 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , References: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> Date: Tue, 22 Mar 2016 17:32:21 +0300 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: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:32:16 -0000 Hi, > > > This version has many significant changes from the previous draft. > Please review it soon so we don't have a lot of surprises in WG Last > Call. > > --Paul Hoffman here is my review of the draft. Most issues are editorial. In a few places text needs to be improved, Section 4.1. needs more explanation text. Otherwise the document looks good. 1. No period at the end of Abstract. 2. Section 1. The IKE protocol itself is also protected by encryption which is negotiated between the two endpoints using IKE. This text is not accurate, since it doesn't mention authentication (MAC), that also protects IKE SA. 3. Section 1. In the text To ensure interoperability, a set of "mandatory-to-implement" IKE encryption algorithms is defined. s/encryption algorithms/cryptographic algorithms 4. Section 1.1 The algorithm implementation requirements and usage guidance may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the main IKEv2 specification and placed in this document. Isn't it better to change: s/in this document/in a separate document (because the guidelines were not only in _this_ document, but also in previous documents) 5. Section 3.1 The algorithms in the below table are negotiated in the SA payload and used for the Encrypted Payload. Isn't "in the table below" more grammatically correct? The same in Section 3.3. 6. Section 3.1 AES-GCM with a 16 octet ICV was not considered as in RFC4307. Shouldn't "as" be removed from grammar point of view? 7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some inconsistency. While the former claims that the advantage of using shorter than 16 bytes ICV are minimal, the latter claims that 8 bytes ICV is enough for IKE SA. Sure, the latter is for IoT use case, but I don't expect that the amount of data transferred over IKE SA in IoT and non-IoT cases is many magnitudes different. I think some other reasons must be given to justify this selection. For example: the majority of existing IoT devices implement ENCR_AES_CCM_8, so we decided to make it mandatory in IKE (well, I don't know if it is true, I'm not familiar with IoT world). 8. Section 3.2 Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed. s/Algorithms/algorithms s/random/pseudorandom 9. Section 3.2 If an algorithm is selected as the integrity algorithm, it SHOULD also be used as the PRF. When using an AEAD cipher, a choice of PRF needs to be made. This text is not clear for me. What do you mean? The PRF needs always be negotiated in IKEv2, regardless of AEAD/non-AEAD cipher. Or do you mean that when non-AEAD cipher is used then PRF and ICV transforms SHOULD be based on the same underlying algorithm? Is it justified somewhere? Well, I can imagine some reasons for it, but I don't like uppervase "SHOULD" here unless you provide some reasoning. 10. Section 3.2 PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based authentication was mentioned. s/authentication/transforms 11. Section 3.2 PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for PRF_HMAC_SHA2_256 or for when stronger security is required. Shouldn't "for when" be "when" from grammatical point of view? The same in Section 3.3. 12. Section 3.2 PRF_AES128_CBC is not in the the IKEv2 IANA registry. There is PRF_AES128_XCBC instead. 13. Section 3.3 There is some disconnect between Sections 3.1 and 3.3. Section 3.1 lists ENCR_AES_CCM_8 as the only preferred choice for IoT. However, ENCR_AES_CCM_8 is AEAD cipher, so if it is used then no separate authentication transform is needed. Why then AUTH_AES_XCBC_96 is listed in Section 3.3 for IoT use case? What encryption transform it is intended to be used with in IoT? 14. Section 3.4 Note that it is critical to enforce a secure Diffie Hellman exchange as this exchange provides encryption for the session. s/encryption/keys s/Diffie Hellman/Diffie-Hellman 15. Section 3.4 If an attacker can retrieve the private numbers (for example a, b) (and? or?) the public values (for example g**a, g**b), then the attacker can compute the secret and the keys used and decrypt the exchange. What is (and? or?)? Is it some leftover? Shouldn't it be just "and"? 16. Section 4.1 RSA Digital Signature is widely deployed and therefor kept for interoperability. s/therefor/therefore 17.Section 4.2 Recommendations for when a hash function is involved in a signature: Shouldn't it be rephrased for more smooth reading? 18. Section 4.2 The last table contains unexplained comment "?SHOULD". 19. Section 4.2 In general this section leaves an impression that it is incomplete and contains disconnects. For example, it states that RSASSA-PSS MUST be implemented, however a few lines below in a table I read: RSASSA-PSS with SHA-256 - SHOULD. I think more explanation text should be added. Regards, Valery Smyslov. From nobody Tue Mar 22 07:45:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79612D90A for ; Tue, 22 Mar 2016 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cxyaNV73AkOj for ; Tue, 22 Mar 2016 07:45:29 -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 E666D12D846 for ; Tue, 22 Mar 2016 07:45:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AF575203C3; Tue, 22 Mar 2016 10:48:01 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B67786375A; Tue, 22 Mar 2016 10:45:21 -0400 (EDT) From: Michael Richardson To: Paul Wouters In-Reply-To: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Date: Tue, 22 Mar 2016 10:45:21 -0400 Message-ID: <16727.1458657921@obiwan.sandelman.ca> Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:45:35 -0000 Paul Wouters wrote: > And replace it with: > For IPv6, ISPs assign either a /48 or /64, so it makes sense to > use a 64-bit prefix as the basis for rate limiting in IPv6. Change it to > For IPv6, ISPs assign between a /48 and a /64, so it makes sense to (it seems that /56 and /60 are the suite spots) -- ] 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 [ From nobody Tue Mar 22 08:01:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805E312D914 for ; Tue, 22 Mar 2016 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 5lVyuvTBDFpV for ; Tue, 22 Mar 2016 08:01:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 3EF0812D863 for ; Tue, 22 Mar 2016 08:01:16 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2MF1BxM018704 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 17:01:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2MF1BKV007226; Tue, 22 Mar 2016 17:01:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22257.24119.666069.8331@fireball.acr.fi> Date: Tue, 22 Mar 2016 17:01:11 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 min Archived-At: Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 15:01:21 -0000 Valery Smyslov writes: > 7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some > inconsistency. While the former claims that the advantage of using > shorter than 16 bytes ICV are minimal, the latter claims that > 8 bytes ICV is enough for IKE SA. Sure, the latter is for IoT use case, > but I don't expect that the amount of data transferred over IKE SA > in IoT and non-IoT cases is many magnitudes different. > I think some other reasons must be given to justify this selection. > For example: the majority of existing IoT devices implement > ENCR_AES_CCM_8, so we decided to make it mandatory in IKE > (well, I don't know if it is true, I'm not familiar with IoT world). It matters when you use things like 802.15.9. IEEE 802.15.9 provides a method to transport IKEv2 messages over IEE Std 802.15.4. In typical PHY of the 802.15.4 the max frame size is 127 bytes, which leaves about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2 packet will require about 3-4 fragments sent in 3-4 frames. Each of those frames will be acknowledged, and there might be timing constrains how often they can be sent (for example in TSCH network this might be once per second at max, when using 10ms slot time, and slotframe size of 100). If we raise the MAC size from 8 to 16, that will cause 8% probability that we need one more frame to send that last part... Also the speeds are low (around 200 kBit/s), and every single byte transmitted consumes power... > 13. Section 3.3 > > There is some disconnect between Sections 3.1 and 3.3. Section 3.1 lists > ENCR_AES_CCM_8 as the only preferred choice for IoT. However, > ENCR_AES_CCM_8 is AEAD cipher, so if it is used then no separate > authentication transform is needed. Why then AUTH_AES_XCBC_96 > is listed in Section 3.3 for IoT use case? What encryption transform > it is intended to be used with in IoT? Because for example 802.15.4 devices use AES_CCM already, thus they do have hardware to do AES_CCM, but they DO NOT have hardware to to AES CBC (there is no AES decryption at all in the hardware). Implementing AEAD is easier as it is just software for IKEv2, than adding AES decryption to hardware. On some other IoT devices the situation might be different. > 15. Section 3.4 > > If an attacker can > retrieve the private numbers (for example a, b) (and? or?) the public > values (for example g**a, g**b), then the attacker can compute the > secret and the keys used and decrypt the exchange. > > What is (and? or?)? Is it some leftover? Shouldn't it be just "and"? Actual "or" is right. I.e., if attacker can get either one of the private numbers, he can compute the secret. -- kivinen@iki.fi From nobody Tue Mar 22 08:22:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75CE12DA10 for ; Tue, 22 Mar 2016 08:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1MGVTqtZiHEo for ; Tue, 22 Mar 2016 08:22:54 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2943712DA65 for ; Tue, 22 Mar 2016 08:22:53 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id qe11so112104331lbc.3 for ; Tue, 22 Mar 2016 08:22:53 -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-transfer-encoding; bh=O80Qo9o7tjqMwTNiJUl+88bm6LsO4idjFGbiySiGj6w=; b=AUTP/Fi8ftbSYfQxBHMHkmKJKD87jQUnlS/SeNp6D4XNmeZwjgmglBPnhIc/PJrrr2 WwIkApncoLVsaSxQB6SiGOgbk5XpoJKoadJYJaKDsIMHQAn5hIB3Qh/4TPCoLWdv/+/R m8pfhxiekZK9cTs63IkUoxEh2aHWDRvR3jBWnMwxqqVqnDHMyBJc7xtpGBKRbCOXqh1L NbSWl0raDHR00NpLyogrxgy5YlIF2QkdL9RDXbEOJBxakOanAAZc2SqLz2uIQbkNSZuO jGAI8ezJAOzAm6JcXhfNZRxRPsmBRY1gaDMq4LsiaEiw6/PIMVuR7fBHST/BxFo75mAY 3+7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=O80Qo9o7tjqMwTNiJUl+88bm6LsO4idjFGbiySiGj6w=; b=ViydhcvrLUCkkNFF+BM1+pNGEol8paY6my5FFv8+AW3e4PzGGeOR+97iRu37Fe171H oQHlA4LOavJF14KzKyhz47D2+cnUYLb3XLduSejd8HQaBwSOUstXKklDqFhIljTG9KpV XzFqUQGHskPMgLBnLxVWRrBpTnxlZr5bPzWvMYkCtfLXfRrZdBpIR6Ph7VCfHQjs26ed 8N/bictLZK+iOJcKrHVB/vdKAbwOcBH/9xBST8egQVZPRKPdaL3a4LvwrV90+iZvCHJa rpK41fTEQZrcgueQX3VGeTW77VzjSnsqt8BDsGJaLdoYy6nqVL2nGjjPg6AK5/mIFsfJ WicA== X-Gm-Message-State: AD7BkJKSOsFHEzQy6WhAvr1JpIjO0edc3DG9LkHogfyievxVpOraqoiz8xtOID4G3CsRSw== X-Received: by 10.25.147.209 with SMTP id v200mr13455898lfd.154.1458660171285; Tue, 22 Mar 2016 08:22:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h192sm5478591lfb.45.2016.03.22.08.22.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 08:22:50 -0700 (PDT) Message-ID: <9D0439B9FE7946B2B31A75D68279DE84@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> <22257.24119.666069.8331@fireball.acr.fi> Date: Tue, 22 Mar 2016 18:23:00 +0300 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: Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 15:22:56 -0000 HI Tero, > Valery Smyslov writes: >> 7. Descriptions for AES-GCM and ENCR_AES_CCM_8 demonstrate some >> inconsistency. While the former claims that the advantage of using >> shorter than 16 bytes ICV are minimal, the latter claims that >> 8 bytes ICV is enough for IKE SA. Sure, the latter is for IoT use case, >> but I don't expect that the amount of data transferred over IKE SA >> in IoT and non-IoT cases is many magnitudes different. >> I think some other reasons must be given to justify this selection. >> For example: the majority of existing IoT devices implement >> ENCR_AES_CCM_8, so we decided to make it mandatory in IKE >> (well, I don't know if it is true, I'm not familiar with IoT world). > > It matters when you use things like 802.15.9. IEEE 802.15.9 provides a > method to transport IKEv2 messages over IEE Std 802.15.4. In typical > PHY of the 802.15.4 the max frame size is 127 bytes, which leaves > about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2 > packet will require about 3-4 fragments sent in 3-4 frames. Each of > those frames will be acknowledged, and there might be timing > constrains how often they can be sent (for example in TSCH network > this might be once per second at max, when using 10ms slot time, and > slotframe size of 100). > > If we raise the MAC size from 8 to 16, that will cause 8% probability > that we need one more frame to send that last part... That's a good reason. Shouldn't this (or similar) explanation be added to the draft? > Also the speeds are low (around 200 kBit/s), and every single byte > transmitted consumes power... That's also a valid reason. Again, shouldn't it be mentioned? >> 13. Section 3.3 >> >> There is some disconnect between Sections 3.1 and 3.3. Section 3.1 lists >> ENCR_AES_CCM_8 as the only preferred choice for IoT. However, >> ENCR_AES_CCM_8 is AEAD cipher, so if it is used then no separate >> authentication transform is needed. Why then AUTH_AES_XCBC_96 >> is listed in Section 3.3 for IoT use case? What encryption transform >> it is intended to be used with in IoT? > > Because for example 802.15.4 devices use AES_CCM already, thus they do > have hardware to do AES_CCM, but they DO NOT have hardware to to AES > CBC (there is no AES decryption at all in the hardware). Implementing > AEAD is easier as it is just software for IKEv2, than adding AES > decryption to hardware. I understand that most IoT devices implement AEAD (AEC-CCM). And in this case there is no need for them to use Integrity Transform at all. But since the draft explicitely lists an Integrity Transform for use in IoT world (AUTH_AES_XCBC_96), then some plain (non-AEAD) Encryption Transform for IoT must also be specified, so that they can be used together. > On some other IoT devices the situation might be different. > >> 15. Section 3.4 >> >> If an attacker can >> retrieve the private numbers (for example a, b) (and? or?) the public >> values (for example g**a, g**b), then the attacker can compute the >> secret and the keys used and decrypt the exchange. >> >> What is (and? or?)? Is it some leftover? Shouldn't it be just "and"? > > Actual "or" is right. I.e., if attacker can get either one of the > private numbers, he can compute the secret. I read this "or" as "if attacker can retrieve private numbers or public values". The attacker can always retrieve public values, - it is not the threat. If the phrase is changed as you suggest - "if attacker can retrieve either one of private numbers" then the phrase makes sense. Regards, Valery. From nobody Wed Mar 23 05:19:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052AB12DC2C for ; Wed, 23 Mar 2016 05:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dFfrTXI4QOvr for ; Wed, 23 Mar 2016 05:19:27 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8841A12DC2F for ; Wed, 23 Mar 2016 05:10:44 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id k12so8508289lbb.1 for ; Wed, 23 Mar 2016 05:10:44 -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; bh=kb/sasPM6v+vjrrLLD2W6DWK0rIcfNrRpjaMzudqACM=; b=vjmr8KIbImGwPqr/WjW7ZxQrgtLmWd/GRZi13iyCEZ40aCc9NVP10T84mHEHpDmut1 tLLYwe3ZPR+6Cp7cpipcubfF2q6GhBnkZ/kTTrozAmxZ0TeX0Yj4nrWKse6crPN+/wuC juyZ67ZveZ9HxkOsd8uMvYOVdb/9xEelOqk4QglXwhYA8TansvCpo4ROF9HnLSjA0KLq DxgMwpbHbrUeZZyPyDBcKuxgZ2MkuBgp4y9Tj8jn+5249OrU6skuvYkhABbuqSZToZ2f XhlO5+4Z/FPxVSunDKFdpDdi7tOHEQiDaItiUo//JvXB+UkiBifqYiO4iOvV8CUKz7Qv k9nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version; bh=kb/sasPM6v+vjrrLLD2W6DWK0rIcfNrRpjaMzudqACM=; b=m8pKGFyzEzobFt3ufzt9zsZCriiIyMuGS1iMEdijWjR+VZ/x2n/ufuq/BhxMtb4cZK wpiOoTGMPlDglPx5MM3ZVLtWBr4H40ghBVbTiu+ZeYPsUguzSh9w6BACET/MLy+zEgwd A99tF0P2k3+6Bha9bFyn7hs5X+deDAQXVwSWMdFoq1W0mEz7F5hLGl7VH+267UC5M9bg nkSCFq9j5tCe70wFSWFGBdfOImGLPJE9xiZ/ykyPvt/8Khv98mxHUgudcJllqSBSVFdR DPTvfHStQdI6qJ4qT5lk5IciK7erefvmSYIGU6LOvUBgcYhcKGWDTKSt7QVVqJQFUzBk fFng== X-Gm-Message-State: AD7BkJL/qwtlUvNQJeTZUsOXGMYzFYUhtXOlkekXZN1ss6tCuFJNkTwPmiwGSCeznzjZag== X-Received: by 10.112.35.162 with SMTP id i2mr1010849lbj.107.1458734600893; Wed, 23 Mar 2016 05:03:20 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id xx7sm355244lbb.19.2016.03.23.05.03.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 05:03:20 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tommy Pauly" , References: Date: Wed, 23 Mar 2016 15:03:16 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08CD_01D18515.21465580" 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: Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 12:19:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_08CD_01D18515.21465580 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tommy, I reviewed the draft.=20 Generally, the draft is in a good shape. It is well written and contains = almost no editorial issues. There are however some places where I'd like to see = more clarification, all of them are listed below. My main problem with the draft is that it has an intended status = Standards Track and=20 at the same time its main goal, as specified in the Introduction, is to = invent some hack to cheat middleboxes that don't pass UDP. In this context the proposal to use TLS (and port 443) looks especially ugly, however it = is probably the most "penetrating" solution. I understand that the world is not = perfect and=20 we must deal with it. However I think that the Standards Track documents = must try to model more or less ideal world (to some extent) and should not = standardize hacks,=20 tricks and so on. On the other hand, TCP encapsulation per se doesn't look bad, and I = think it is worth=20 to have standard interoperable solution to encapsulate IKE and ESP in = TCP.=20 I would have had much less problems with this proposal it the draft was = splitted=20 into two documents - one Standards Track document describing TCP = encapsulation per se, and the other Informational document describing all the hacks = and tricks=20 to cheat the middleboxes that try not to pass anything except e.g. http = and/or https. And I'd like all the TLS encapsulation stuff go into that draft. 1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be = preferred over using TCP Encapsulation is present twice in the document (in Sections 1 and = 2). I think it's OK to reemphasize=20 this requirement, however since both of them use RFC2119 language, = they look duplicated.=20 I'd suggest to change one of the SHOULDs to lower case. 2. Section 3. Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. The maximum message length is used as the effective MTU for connections that are being encrypted using ESP, so the maximum message length will influence characteristics of inner connections, such as the TCP Maximum Segment Size (MSS). this text is not clear for me. IKE and ESP message length can be up to 64Kbytes, so how it can be used as effective MTU (that is less = than or equal to the interface MTU, that is usually about 1500 bytes)? How it can influence MSS, that is usually less than or equal to=20 path MTU to avoid IP fragmentation? Am I missing something? 3. Section 4. Any specific IKE SA, along with its Child SAs, is either TCP encapsulated or not. A mix of TCP and UDP encapsulation for a single SA is not allowed. The exception to this rule is SAs that are migrated between addresses using MOBIKE Section 7. the last sentence is not accurate. As far as I understand, if IKE SA = (along with=20 its Child SAs) migrated from one address to another via MOBIKE, then = either all these SAs (IKE & its children) use TCP encapsulation or all them use traditional encapsulation. So, it is not an = exception from the rule. Well, my reading of the rule that "the mix is not = allowed" is that by "mix" you mean situation when IKE SA uses one type of encapsulation while some of its children use different type. I'd suggest to clarify this text so that any ambiguity is = eliminated. =20 4. Section 5. A peer must discard a partially received message due to a broken connection. s/must/MUST ? 5. Section 9. NAT keep-alive packets over a TCP encapsulated IPSec connection will be sent with a length value of 1 byte, whose value is 0xFF Figure 2. Shouldn't "Figure 2" be enclosed in brackets? 6. Section 11. There is no subsection describing additional overhead to the size of = the ESP=20 and IKE messages when using TCP encapsulation. This overhead may be important for some implementations. Consider = some application (e.g. VoIP) that sends small packets, e.g. about 50 = bytes in size. With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = =3D 36 bytes. With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) = =3D 52 bytes. The difference may be significant for low bandwith networks or low = power consumption devices. With TLS the situation will be worse. 7. Section 11.3 =20 It is not clear from the text where NULL cipher should be used - in = ESP or in TLS? If it is about TLS, then does by NULL cipher you mean TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS=20 (I'm not a TLS expert)? If it is about ESP NULL cipher,=20 then it contradicts to last para in Section 12... I think it should = be clarified. 8. The draft is silent about ESP Sequence Numbers. I think a few words = could=20 be added that while the ESP SN are unnecessary with TCP = encapsulation, the sender still must increnet it in every sent packet. Regards, Valery Smyslov. =20 ----- Original Message -----=20 From: Tommy Pauly=20 To: ipsec@ietf.org=20 Sent: Tuesday, February 16, 2016 12:52 AM Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft Hello all, I=E2=80=99ve just posted a new version of the IKEv2 and IPSec TCP = Encapsulation draft. The changes include: - Making the use case (as a last resort if UDP is blocked) more clear = in the introduction - Clarify connection establishment and teardown section (allowing a = resumed connection to start with either IKE or ESP traffic, allowing = multiple SAs on one TCP connection) - Adding more details about interactions with IKEv2 fragmentation, and = TCP MSS and QoS markings - Clarifying the keep-alive/DPD section - A new appendix written by a new author from Cisco giving four = example exchanges with TCP encapsulation of IKEv2. https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 I believe this should address many of the comments the last draft = received. Please take a look and provide your feedback! If the working = group is in favor, I=E2=80=99d like to see if this can be adopted by the = working group. Thanks, Tommy -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_08CD_01D18515.21465580 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Tommy,
 
I reviewed the draft.
 
Generally, the draft is in a good shape. It is well = written=20 and contains almost no
editorial issues. There are however some places = where I'd like=20 to see more
clarification, all of them are listed = below.
 
My main problem with the draft is that it has an = intended=20 status Standards Track and
at the same time its main goal, as specified in the=20 Introduction, is to invent
some hack to cheat middleboxes that don't pass = UDP. In=20 this context
the proposal to use TLS (and port 443) looks = especially ugly,=20 however it is probably
the most "penetrating" solution. I understand that = the world=20 is not perfect and
we must deal with it. However I think that the = Standards Track=20 documents must try
to model more or less ideal world (to some extent)=20 and should not standardize hacks,
tricks and so on.
 
On the other hand, TCP encapsulation per se doesn't = look bad,=20 and I think it is worth
to have standard interoperable = solution to=20 encapsulate IKE and ESP in TCP.
I would have had much less problems with this = proposal it the=20 draft was splitted
into two documents - one Standards Track document = describing=20 TCP encapsulation
per se, and the other Informational document = describing all=20 the hacks and tricks
to cheat the middleboxes that try not to pass = anything except=20 e.g. http and/or https.
And I'd like all the TLS encapsulation stuff go into = that=20 draft.
 
 
 
1. The requirement that direct use of ESP or UDP = Encapsulation=20 SHOULD be preferred over using TCP
    Encapsulation is present twice in = the=20 document (in Sections 1 and 2). I think it's OK to reemphasize =
    this requirement, however since = both of=20 them use RFC2119 language, they look duplicated.
    I'd suggest to change one of the = SHOULDs to=20 lower case.
 
2. Section 3.
 
   Although a TCP stream may be able = to send=20 very long messages,
   implementations SHOULD limit message = lengths=20 to typical UDP datagram
   ESP payload lengths.  The = maximum=20 message length is used as the
   effective MTU for = connections that=20 are being encrypted using ESP, so
   the maximum message = length=20 will influence characteristics of inner
   connections, = such as the=20 TCP Maximum Segment Size (MSS).
    this text is not clear for me. = IKE and=20 ESP message length can be up
    to 64Kbytes, so how it can be = used as=20 effective MTU (that is less than or
    equal to the interface MTU, that = is usually=20 about 1500 bytes)?
    How it can influence MSS, that is = usually=20 less than or equal to
    path MTU to avoid IP = fragmentation? Am I=20 missing something?
 
3. Section 4.
 
   Any specific IKE SA, along with its = Child SAs, is=20 either TCP
   encapsulated or not.  A mix of TCP and = UDP=20 encapsulation for a single
   SA is not allowed.  The=20 exception to this rule is SAs that are
   migrated between=20 addresses using MOBIKE Section 7.
 
    the last sentence is = not=20 accurate. As far as I understand, if IKE SA (along with
    its Child SAs) migrated=20 from one address to another via MOBIKE, then
    either all these SAs (IKE & = its=20 children) use TCP encapsulation
    or all them use traditional = encapsulation.=20 So, it is not an exception
    from the rule. Well, my reading = of the=20 rule that "the mix is not allowed"
    is that by "mix" you mean = situation when=20 IKE SA uses one type
    of encapsulation while some of = its children=20 use different type.
    I'd suggest to clarify this text = so that=20 any ambiguity is eliminated.
   
4. Section 5.
 
   A peer must discard a partially = received message=20 due to a broken
   connection.
 
    s/must/MUST ?
 
5. Section 9.
 
    NAT keep-alive packets over a=20 TCP
   encapsulated IPSec connection will be sent with a = length=20 value of 1
   byte, whose value is 0xFF Figure = 2.
 
    Shouldn't "Figure 2" be enclosed = in=20 brackets?
 
6. Section 11.
 
    There is no subsection describing = additional overhead to the size of the ESP
    and IKE messages when using TCP=20 encapsulation.
    This overhead may be important = for some=20 implementations. Consider some
    application (e.g. VoIP) that = sends small=20 packets, e.g. about 50 bytes in size.
    With UDP encapsulation the = overhead=20 is 8 (ESP) + 8 (UDP) + 20 (IP) =3D 36 bytes.
    With TCP encapsulation it is 8 = (ESP)=20 + 4 (len) + 20 (TCP) + 20 (IP) =3D 52 bytes.
    The difference may be significant = for low=20 bandwith networks or low power consumption
    devices. With TLS the situation = will be=20 worse.
 
7. Section 11.3
   
    It is not clear from the text = where NULL=20 cipher should be used - in ESP
    or in TLS? If it is about TLS, = then does by=20 NULL cipher you mean
    TLS_NULL_WITH_NULL_NULL or = something else?=20 Is it MTI in TLS
    (I'm not a TLS = expert)? If it is about ESP NULL = cipher,=20
    then it contradicts to last para = in Section=20 12... I think it should be clarified.
 
8. The draft is silent about ESP Sequence Numbers. I = think a=20 few words could
    be added that while the ESP SN = are=20 unnecessary with TCP encapsulation,
    the sender still must increnet = it in=20 every sent packet.
 
Regards,
Valery Smyslov.
   
 
 
 
----- Original Message -----
From:=20 Tommy = Pauly=20
Sent: Tuesday, February 16, = 2016 12:52=20 AM
Subject: [IPsec] New version of = IKEv2 TCP=20 Encapsulation draft

Hello all,

I=E2=80=99ve just posted a new version of the IKEv2 and IPSec TCP = Encapsulation=20 draft. The changes include:

- Making the use case (as a last resort if UDP is blocked) more = clear in=20 the introduction
- Clarify connection establishment and teardown section (allowing = a=20 resumed connection to start with either IKE or ESP traffic, allowing = multiple=20 SAs on one TCP connection)
- Adding more details about interactions with IKEv2 = fragmentation, and=20 TCP MSS and QoS markings
- Clarifying the keep-alive/DPD section
- A new appendix written by a new author from Cisco giving four = example=20 exchanges with TCP encapsulation of IKEv2.

= https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt
=
ht= tps://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03

I believe this should address many of the comments the last draft = received. Please take a look and provide your feedback! If the working = group=20 is in favor, I=E2=80=99d like to see if this can be adopted by the = working=20 group.

Thanks,
Tommy

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_08CD_01D18515.21465580-- From nobody Wed Mar 23 12:54:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69812D86F for ; Wed, 23 Mar 2016 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jk5-El-YA9ce for ; Wed, 23 Mar 2016 12:54:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D4912D86E for ; Wed, 23 Mar 2016 12:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12133; q=dns/txt; s=iport; t=1458762861; x=1459972461; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lLetq1Qv9Nr4Ftb1XHMvPVsgrxRAKyZHbIQQzdHI5AU=; b=cSXJUd8NmCpiEwTBFH//M0aW59aF812otxaFTcVUeE0kpBKyJI6fnoQx Dv7GVB+luuuUq9Dy0HRjMuYTIqSgOIMeyBXBeFfqx88OsUN2kS0jBr+DL xUWAT+lldmUsgKggDhomS+LYgT10oRMeDK/u//OFVYcFTJ3qd++3T6+iv s=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAgAE8/JW/5FdJa1VCYMzgU0GrwiJP?= =?us-ascii?q?4IPDoFwhg0CJYEZOBQBAQEBAQEBZCeEQgEBBCNWEAIBBgIONAICAh8RJQIEAQ0?= =?us-ascii?q?FDguHeQMSkz+dF4t1DYRiAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGHoREgj6BV?= =?us-ascii?q?QM8gmqCVgWTBIQlMQGDHYFmhwuBdYFmhEyDJ4UxhzKHVAEeAUOCAwUUgUlqiFA?= =?us-ascii?q?iG34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,383,1454976000"; d="p7s'?scan'208";a="85983657" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2016 19:54:20 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2NJsKDb021024 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 19:54:20 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 14:54:19 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 14:54:20 -0500 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Paul Wouters , "IPsecME WG" , "Waltermire, David A. (Fed)" Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 Thread-Index: AQHRgWKQEN1mpUdbReie8Bmkunv/FZ9iOI+AgAD2dYCAALClH4AD7PSA Date: Wed, 23 Mar 2016 19:54:19 +0000 Message-ID: References: <8E7A385FFC124F60A313BB202FC81979@chichi> <3755B9EF6414459584A2A5210E60E52C@buildpc> In-Reply-To: <3755B9EF6414459584A2A5210E60E52C@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.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.203.162] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3541607657_9165015" MIME-Version: 1.0 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:54:24 -0000 --B_3541607657_9165015 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Valery / Tero=20 Sorry for the late reply. GB> Comments inline. cheers On 21/03/2016 12:57, "Valery Smyslov" wrote: >I don't think we are in a position to impose such a requirement in the >draft. GB>I feel we should explain WHY it=E2=80=99s a security benefit to link the ID an= d certificate. Not to mandate anything. As you said, currently the RFC states that ID does not have to match certifciate, but I feel this increases the attack surface for authenticated DoS attacks. >RFC 7296 doesn't have a requirement that an ID must be present in the >certificate. Moreover, Section 3.5. explicitely allows ID be different >from any field in certfificate: > > The Identification payloads, denoted IDi and IDr in this document, > allow peers to assert an identity to one another. This identity may > be used for policy lookup, but does not necessarily have to match > anything in the CERT payload; both fields may be used by an > implementation to perform access control decisions. When using the > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > does not require this address to match the address in the IP header > of IKEv2 packets, or anything in the TSi/TSr payloads. The contents > of IDi/IDr are used purely to fetch the policy and authentication > data related to the other party. > >There are many good reasons not to to impose such a requirement - >there are many use cases when ID payload just cannot be directly >mapped to credentials (preshared keys, some EAP methods, raw public >keys etc.), so the mapping is performed via Local Policy. >It allows more flexibility in real life, but at the same time it requires >Local Policy to be written with care. GB>I=E2=80=99m only proposing this for digital signatures where there is a cryptographically signed identity in this instance. I=E2=80=99m not suggesting it should be advised for other ID types (I couldn=E2=80=99t see the benefits). > >In your example there is a clear configuration error, and I don't think >we could do anything about this on RFC level. >Next time IT engineer issues two certificates with equal FQDNs >to two different people and the situation you described happens again, >even if SGW will check the match betweed ID and certificate... > >>For the malicious example, it=D0=B2=D0=82=E2=84=A2s easy to spoof an ID, but it=D0=B2=D0=82=E2=84=A2s >>computationally impossible to spoof a certificate, hence the >>ID-Certificate check will mitigate any mis-conftguation or malicious >>intention. The behaviour of INITIAL_CONTACT is really being exploited in >>this case (IMO). > >No, I don't think so. To exploit this mis-configuration a malicious user >must be >authenticated by SGW. So, he/she is not an unknown attacker, he/she does >have >proper credentials. In this case he/she can be traced down >and the out-of-band measures can be taken. GB>Sure - they can be tracked down, but if we could prevent the opportunity to perform malicious behaviour surely that would be beneficial, rather than tracking down someone after the event. I=E2=80=99ll provide another scenario of malicious intent, where not having a ID to Cert check increases the attack surface; A mobile device configured to use certificates is lost and compromised (private key extracted). If the attacker knows the IKE ID used by all other members of the Gateway prior to the certificate being revoked the attacker could authenticate to the Gateway as all other IKE ID's (as the compromised certificate will pass authentication). In this instance when INITIAL_CONTACT is used the attacker will be able to delete the legitimate users active sessions. For VPN Gateways that serve both Remote Access and Site-to-site VPNs this would have maximum impact, taking out a site-site connection. For the case for IoT device it could be weeks before someone realised a device is compromised, which increases the attack surface even further. > >>GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, >>not just RFC7619, so if someone is looking to protect RFC7296 against >>DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but >>there=D0=B2=D0=82=E2=84=A2s still cases (and seem to be common) where it can happen. > >The draft has a reference to RFC7619. In general, NULL auth is not >relevant to DoS protection >unless your product supports it. And in this case you have to read RFC >7619 anyway >while adding support, right? > >>>Again, allocation of IP addresses takes place after user authentication, >>>so it cannot be used as DoS attack by malicious user. >> >>GB> Think of mischievous users or misconfigured, as anyone who CAN pass >>authentication. Let me give you this example. I=D0=B2=D0=82=E2=84=A2m granted access to= a >>VPN >>gateway for 24 hours, where a security policy is applied so that I only >>access read access to a single file. I=D0=B2=D0=82=E2=84=A2m an =D0=B2=D0=82=C2=98untrusted=D0=B2=D0=82=E2=84=A2 = user, this >>gateway >>also serves =D0=B2=D0=82=E2=84=A2trusted=D0=B2=D0=82=E2=84=A2 users. I am granted very limited access= . I >>exhaust >>the pool of IP addresses so that no other (legitimate) users can connect. >>This is similar to DHCP exhaustion on a LAN. We can mitigate against that >>(DHCP snooping etc), I feel that we should protect IKE from a similar >>attack. >> >>GB> I=D0=B2=D0=82=E2=84=A2m seeing a lot of cases (IoT), where IKE is used, however the >>devices aren=D0=B2=D0=82=E2=84=A2t secured and are not really trusted. Examples are; >>Sensor on >>a pole in the middle of no-where, or unsecured in a lift shaft. For the >>IoT case although the authentication exchange passes, the client still >>isn=D0=B2=D0=82=E2=84=A2t fully trusted, so we should protect the control-plane (IKE) a= s >>best >>we can. >> >>GB> FWIW - I feel that the text in section 8 does sort of cover this, but >>wanted to describe the issue and if others feel the text doesn=D0=B2=D0=82=E2=84=A2t >>adequately mitigate the issue of IP address exhaustion I can add some >>words. > >Could you please describe how you exhaust the pool of IP addresses? >If you are authenticated user you'll receive the same IP address no matter >how many times you ask for it (in general it depends on SGW >implementation, >I assume SGW links client ID with IP from poll). GB>After a bit more digging, the exploit I thought I had found would require the implementation to be broken. > >If you use NULL auth, then it is a different story, but I think >RFC 7619 describes the risks of using NULL auth. > >Regards, >Valery. --B_3541607657_9165015 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+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg/6iG 6pEki5jzj80xk2KYMQKtX5prK8P2KOH3ub3r8BswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwMzIzMTk1NDE3WjANBgkqhkiG9w0BAQEFAASCAQCX5wPV 1fkY9wdR6rSjarf9SYDDRRLs/hWTc1sJ/DUkUMwSqvD3CmZinRlNUe5ZVAJ1hnjSZAgRLfbp bp5/OwdtghoOhtTipEpceQoiUaVlNUErkwit9QkFGdcuB+7LW3dMsZ3/uXXM/Y716Iexn0To Ka3YmSOEaH7yU+yrHg0UIq2gx1Y9ogaiICc79cn/h8yAaxossIINGuWLIPDfZUrA57neZ4so uyusRcnmWro6Xw6zOqgv5EIg7a7R7rUAIl9uVZ/97v74ZUx6QnAGYXONujAQZ458L6yq4xJ4 REdnJ+mVtQf4zZffG2ablJm2B+h4OvOox+9hXAY9Vy2H0wO4 --B_3541607657_9165015-- From nobody Wed Mar 23 14:01:37 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF71612D8E5 for ; Wed, 23 Mar 2016 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 w3rLOVnQVcQk for ; Wed, 23 Mar 2016 14:01:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 7090F12D566 for ; Wed, 23 Mar 2016 14:01:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2NL1UeM008189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Mar 2016 23:01:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2NL1TB0020592; Wed, 23 Mar 2016 23:01:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22259.1065.700884.653781@fireball.acr.fi> Date: Wed, 23 Mar 2016 23:01:29 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <9D0439B9FE7946B2B31A75D68279DE84@buildpc> References: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> <22257.24119.666069.8331@fireball.acr.fi> <9D0439B9FE7946B2B31A75D68279DE84@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 21:01:36 -0000 Valery Smyslov writes: > > It matters when you use things like 802.15.9. IEEE 802.15.9 provides a > > method to transport IKEv2 messages over IEE Std 802.15.4. In typical > > PHY of the 802.15.4 the max frame size is 127 bytes, which leaves > > about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2 > > packet will require about 3-4 fragments sent in 3-4 frames. Each of > > those frames will be acknowledged, and there might be timing > > constrains how often they can be sent (for example in TSCH network > > this might be once per second at max, when using 10ms slot time, and > > slotframe size of 100). > > > > If we raise the MAC size from 8 to 16, that will cause 8% probability > > that we need one more frame to send that last part... > > That's a good reason. Shouldn't this (or similar) explanation be > added to the draft? Perhaps. How much of current information we want to put in the document. The things are changing all the time, and it might be true now for IoT, but might not be true in few years. Isn't enough to just say that currently this algorithm might be used for IoT. > > Also the speeds are low (around 200 kBit/s), and every single byte > > transmitted consumes power... > > That's also a valid reason. Again, shouldn't it be mentioned? Same as above. > > Because for example 802.15.4 devices use AES_CCM already, thus they do > > have hardware to do AES_CCM, but they DO NOT have hardware to to AES > > CBC (there is no AES decryption at all in the hardware). Implementing > > AEAD is easier as it is just software for IKEv2, than adding AES > > decryption to hardware. > > I understand that most IoT devices implement AEAD (AEC-CCM). > And in this case there is no need for them to use Integrity Transform at all. > But since the draft explicitely lists an Integrity Transform for use > in IoT world (AUTH_AES_XCBC_96), then some plain (non-AEAD) > Encryption Transform for IoT must also be specified, > so that they can be used together. AUTH_AES_XCBC_96 was there for before because it was replacement for SHA-1 for general use, not only for IoT. When it was not taken in to the use, it could also be removed or downgraded lower. On the other there might be IoT devices which do not implement AES-CCM on hardware, so AES-CBC + AUTH_AES_XCBC_96 might be suitable combination for them. AES-CBC is already mandatory so there is no point of marking it as IoT only. > >> If an attacker can > >> retrieve the private numbers (for example a, b) (and? or?) the public > >> values (for example g**a, g**b), then the attacker can compute the > >> secret and the keys used and decrypt the exchange. > >> > >> What is (and? or?)? Is it some leftover? Shouldn't it be just "and"? > > > > Actual "or" is right. I.e., if attacker can get either one of the > > private numbers, he can compute the secret. > > I read this "or" as "if attacker can retrieve private numbers or > public values". The attacker can always retrieve public values, - it > is not the threat. If the phrase is changed as you suggest - "if > attacker can retrieve either one of private numbers" then the phrase > makes sense. True, public values is know always, so there is no point of "retrieving" them, I assumed it was supposed to be "(for example a, or b)". In that case we could have also "and as attacker usually knows pulic values"... -- kivinen@iki.fi From nobody Thu Mar 24 13:04:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4941712D839 for ; Thu, 24 Mar 2016 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ouDotScAf9gX for ; Thu, 24 Mar 2016 13:04:08 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236C712D841 for ; Thu, 24 Mar 2016 13:04:06 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-97-56f442a0e8c7 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.8B.30335.0A244F65; Thu, 24 Mar 2016 20:40:16 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 24 Mar 2016 16:04:05 -0400 From: Samy Touati To: Valery Smyslov , Tommy Pauly , "ipsec@ietf.org" Thread-Topic: [IPsec] New version of IKEv2 TCP Encapsulation draft Thread-Index: AQHRhP5LLwV1/XxXlUuYUsasxa1cS59o1FcA Date: Thu, 24 Mar 2016 20:04:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160323 x-originating-ip: [147.117.188.10] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3541669442_1434563220" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUyuXRPlO4Cpy9hBhO75C32b3nBZnHjw0w2 i4knDrI6MHtsPfmDzWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyvjx5B9rwa05TBWXNi9m a2B89Iexi5GTQ0LARGL+2aXMELaYxIV769m6GLk4hASOMErsnz+DGcJZzihx8fJVNpAqNgEd icubZ7B0MXJwiAhkSeza7g4SFhZwlNjTeo8JxBYRcJJonf6AHcI2kuia/oQVxGYRUJXoaJsD VsMrYC/xbssbsJFCApkSfy+vYgGxOQXMJVav+ApWwyggK7H77HUwm1lAXOLWk/lMEIeKSDy8 eJoNwhaVePn4H9h8UQFdiYUzuqEeU5KYtPQcK0RvpcSvnllsEHsFJU7OfMIygVF0FpKxs5CU zUJSBhH3lJj4soMVwtaW2HNrKzOM/eTdBai4lsSVG4fZMcWtJWb8OsgGYStKTOl+CFVjKvH6 6EfGBYzcqxg5SosLcnLTjQw2MQKj+ZgEm+4OxvvTPQ8xCnAwKvHwfpD/HCbEmlhWXJl7iFEF qPXRhtUXGKVY8vLzUpVEeLepfwkT4k1JrKxKLcqPLyrNSS0+xCjNwaIkzrv+7eUwIYH0xJLU 7NTUgtQimCwTB6dUA6N+SsCxN7FTElvP3zWcOWv+BO7QdSnuOyOvxRrkZDizPGFg0TaV8vmw fr3lFxPhP1l1/LmlVbenyMR6n6h5ryDcZV0jIPZg2uq3lzgE9Ke9NfnI2f0ic9v2B23F8vcT V4f8PPZz27etGb3J3/slSndYTt/0MeFB8cN/L/8/0up6e1XLIc5y52QlluKMREMt5qLiRAB1 tTUW7gIAAA== Archived-At: Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 20:04:11 -0000 --B_3541669442_1434563220 Content-type: multipart/alternative; boundary="B_3541669442_1101298664" --B_3541669442_1101298664 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Valery, =20 I agree with you that the TLS/HTTPS should be separated from the main TCP e= ncapsulation descriptions, but I think it must stay in the current draft and= moved to an appendix section at the end of the draft.=20 The purpose is to show why TCP encapsulation is required in the first place= . =20 Thanks. Samy. =20 =20 From: IPsec on behalf of Valery Smyslov Date: Wednesday, March 23, 2016 at 5:03 AM To: Tommy Pauly , "ipsec@ietf.org" Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft =20 Hi Tommy, =20 I reviewed the draft.=20 =20 Generally, the draft is in a good shape. It is well written and contains al= most no editorial issues. There are however some places where I'd like to see more clarification, all of them are listed below. =20 My main problem with the draft is that it has an intended status Standards = Track and=20 at the same time its main goal, as specified in the Introduction, is to inv= ent some hack to cheat middleboxes that don't pass UDP. In this context the proposal to use TLS (and port 443) looks especially ugly, however it is= probably the most "penetrating" solution. I understand that the world is not perfect= and=20 we must deal with it. However I think that the Standards Track documents mu= st try to model more or less ideal world (to some extent) and should not standardi= ze hacks,=20 tricks and so on. =20 On the other hand, TCP encapsulation per se doesn't look bad, and I think i= t is worth=20 to have standard interoperable solution to encapsulate IKE and ESP in TCP.=20 I would have had much less problems with this proposal it the draft was spl= itted=20 into two documents - one Standards Track document describing TCP encapsulat= ion per se, and the other Informational document describing all the hacks and t= ricks=20 to cheat the middleboxes that try not to pass anything except e.g. http and= /or https. And I'd like all the TLS encapsulation stuff go into that draft. =20 =20 =20 1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be pr= eferred over using TCP Encapsulation is present twice in the document (in Sections 1 and 2). I= think it's OK to reemphasize=20 this requirement, however since both of them use RFC2119 language, they= look duplicated.=20 I'd suggest to change one of the SHOULDs to lower case. =20 2. Section 3. =20 Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. The maximum message length is used as the effective MTU for connections that are being encrypted using ESP, so the maximum message length will influence characteristics of inner connections, such as the TCP Maximum Segment Size (MSS). this text is not clear for me. IKE and ESP message length can be up to 64Kbytes, so how it can be used as effective MTU (that is less than = or equal to the interface MTU, that is usually about 1500 bytes)? How it can influence MSS, that is usually less than or equal to=20 path MTU to avoid IP fragmentation? Am I missing something? =20 3. Section 4. =20 Any specific IKE SA, along with its Child SAs, is either TCP encapsulated or not. A mix of TCP and UDP encapsulation for a single SA is not allowed. The exception to this rule is SAs that are migrated between addresses using MOBIKE Section 7. =20 the last sentence is not accurate. As far as I understand, if IKE SA (a= long with=20 its Child SAs) migrated from one address to another via MOBIKE, then=20 either all these SAs (IKE & its children) use TCP encapsulation or all them use traditional encapsulation. So, it is not an exception from the rule. Well, my reading of the rule that "the mix is not allowe= d" is that by "mix" you mean situation when IKE SA uses one type of encapsulation while some of its children use different type. I'd suggest to clarify this text so that any ambiguity is eliminated. =20 4. Section 5. =20 A peer must discard a partially received message due to a broken connection. =20 s/must/MUST ? =20 5. Section 9. =20 NAT keep-alive packets over a TCP encapsulated IPSec connection will be sent with a length value of 1 byte, whose value is 0xFF Figure 2. =20 Shouldn't "Figure 2" be enclosed in brackets? =20 6. Section 11. =20 There is no subsection describing additional overhead to the size of th= e ESP=20 and IKE messages when using TCP encapsulation. This overhead may be important for some implementations. Consider some application (e.g. VoIP) that sends small packets, e.g. about 50 bytes i= n size. With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) =3D 36= bytes. With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) =3D 5= 2 bytes. The difference may be significant for low bandwith networks or low powe= r consumption devices. With TLS the situation will be worse. =20 7. Section 11.3 =20 It is not clear from the text where NULL cipher should be used - in ESP or in TLS? If it is about TLS, then does by NULL cipher you mean TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS=20 (I'm not a TLS expert)? If it is about ESP NULL cipher,=20 then it contradicts to last para in Section 12... I think it should be = clarified. =20 8. The draft is silent about ESP Sequence Numbers. I think a few words coul= d=20 be added that while the ESP SN are unnecessary with TCP encapsulation, the sender still must increnet it in every sent packet. =20 Regards, Valery Smyslov. =20 =20 =20 =20 ----- Original Message -----=20 From: Tommy Pauly=20 To: ipsec@ietf.org=20 Sent: Tuesday, February 16, 2016 12:52 AM Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft =20 Hello all,=20 =20 I=E2=80=99ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation d= raft. The changes include: =20 - Making the use case (as a last resort if UDP is blocked) more clear in th= e introduction - Clarify connection establishment and teardown section (allowing a resumed= connection to start with either IKE or ESP traffic, allowing multiple SAs o= n one TCP connection) - Adding more details about interactions with IKEv2 fragmentation, and TCP = MSS and QoS markings - Clarifying the keep-alive/DPD section - A new appendix written by a new author from Cisco giving four example exc= hanges with TCP encapsulation of IKEv2. =20 https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 =20 I believe this should address many of the comments the last draft received.= Please take a look and provide your feedback! If the working group is in fa= vor, I=E2=80=99d like to see if this can be adopted by the working group. =20 Thanks, Tommy =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --B_3541669442_1101298664 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Valery,

 

I agree with = you that the TLS/HTTPS should be separated from the main TCP encapsulation d= escriptions, but I think it must stay in the current draft and moved to an a= ppendix section at the end of the draft.
The purpose is to show why TCP = encapsulation is required in the first place.

 

Thanks.

Samy.

=  <= /p>

 

From: IPsec <ipsec-bounces@ietf.org> on behalf of Valery Smyslov &= lt;svanru@gmail.com>
Date: Wednesday, March 23, 2016 at 5:03 AM=
To: Tommy Pauly <tpauly@apple.com>, "ipsec@ietf.org&qu= ot; <ipsec@ietf.org>
Subject: Re: [IPsec] New version of IKE= v2 TCP Encapsulation draft

 

Hi Tommy,

 

I reviewed the draft.

 

Generally, the draft is in a good shape. It is well written and= contains almost no

editorial issues. There are however some places wh= ere I'd like to see more

= clarification, all of them are listed below.<= /span>

 

My main problem wit= h the draft is that it has an intended status Standards Track and

at = the same time its main goal, as specified in the Introduction, is to invent<= /span>

some hack to cheat middleboxes that don't pass UDP. In this conte= xt

the proposal to use TLS (and port 443) looks especially ugly, howev= er it is probably

the most "penetrating" solution. I underst= and that the world is not perfect and

we must deal with it. However I= think that the Standards Track documents must try

to model more or le= ss ideal world (to some extent) and should not standardize hacks, =

tricks and so on.

=  

On the other hand, TCP encapsulation per se doesn't look bad, and I th= ink it is worth

to have standard interoperable solution to encapsulat= e IKE and ESP in TCP.

I would have had much less problems with this p= roposal it the draft was splitted

into two documents - one Standards = Track document describing TCP encapsulation

=

per se, and the other Info= rmational document describing all the hacks and tricks

to cheat = the middleboxes that try not to pass anything except e.g. http and/or https.=

And I'd like all the TLS encapsulation stuff go into that draft.

 

 

&nb= sp;

1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be = preferred over using TCP

=     Encapsulation is present t= wice in the document (in Sections 1 and 2). I think it's OK to reemphasize <= /span>

    this requirement, however since both of them use RF= C2119 language, they look duplicated.

=

    I'd sug= gest to change one of the SHOULDs to lower case.

=

 

<= span style=3D'font-size:10.0pt'>2. Section 3.

=

 

   Although a TCP stream may be able= to send very long messages,
   implementations SHOULD limit me= ssage lengths to typical UDP datagram
   ESP payload lengths.&n= bsp; The maximum message length is used as the
   effective MTU= for connections that are being encrypted using ESP, so
   the = maximum message length will influence characteristics of inner
 &nbs= p; connections, such as the TCP Maximum Segment Size (MSS).

 &nbs= p;  this text is not clear for me. IKE and ESP message length can = be up

    to 64Kbytes, so how it can be used as effecti= ve MTU (that is less than or

    equal to the inte= rface MTU, that is usually about 1500 bytes)?

    How i= t can influence MSS, that is usually less than or equal to

 &nbs= p;  path MTU to avoid IP fragmentation? Am I missing something?<= o:p>

 

=

3. Section 4.<= /o:p>

 

   Any specific IKE S= A, along with its Child SAs, is either TCP
   encapsulated or n= ot.  A mix of TCP and UDP encapsulation for a single
   SA= is not allowed.  The exception to this rule is SAs that are
 &= nbsp; migrated between addresses using MOBIKE Section 7.

 

    the last sente= nce is not accurate. As far as I understand, if IKE SA (along with

    its Child SAs) migrated from one address to another&nb= sp;via MOBIKE, then

    either all these SAs (IKE &= ; its children) use TCP encapsulation

    or all them u= se traditional encapsulation. So, it is not an exception

  &= nbsp; from the rule. Well, my reading of the rule that "the mix is= not allowed"

    is that by "mix" you m= ean situation when IKE SA uses one type

    of encapsul= ation while some of its children use different type.

   = ; I'd suggest to clarify this text so that any ambiguity is eliminated.

   

4. Section 5.

 

   A peer must discard a partially received= message due to a broken
   connection.

 

    s/must/MUST ?

 

5. Section 9.

 

    NAT keep-alive= packets over a TCP
   encapsulated IPSec connection will be se= nt with a length value of 1
   byte, whose value is 0xFF Figure= 2.

 

=

  &nb= sp; Shouldn't "Figure 2" be enclosed in brackets?

 

6. Section 11.

 

    There is no subsecti= on describing additional overhead to the size of the ESP

&n= bsp;   and IKE messages when using TCP encapsulation.<= /o:p>

 =    This overhead may be important for some implementations. Consid= er some

    application (e.g. VoIP) that sends small pa= ckets, e.g. about 50 bytes in size.

    With = UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP)= =3D 36 bytes.

    With TCP encapsulation it is 8 (ESP) +=  4 (len) + 20 (TCP) + 20 (IP) =3D 52 bytes.

   = The difference may be significant for low bandwith networks or low pow= er consumption

    devices. With TLS the situation will= be worse.

 

7. Secti= on 11.3

   

    It is not clear f= rom the text where NULL cipher should be used - in ESP

=

  &nb= sp; or in TLS? If it is about TLS, then does by NULL cipher you mean<= o:p>

&= nbsp;   TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TL= S

    (I'm not a TLS expert)? If it is about = ;ESP NULL cipher,

    then it contradicts to last para= in Section 12... I think it should be clarified.

 

= 8. The draft is silent about ESP Sequence Num= bers. I think a few words could

    be added that whil= e the ESP SN are unnecessary with TCP encapsulation,

   = ; the sender still must increnet it in every sent packet.

 

Regards,

Valery Smyslov.

   

=  

 

 

----- Original Me= ssage -----

To: ipsec@ietf.org <= /o:p>

Sent: Tuesday, February 16, 2016 12:52 AM

<= div>

S= ubject: [IPsec] = New version of IKEv2 TCP Encapsulation draft

 

Hello all,=

 

I’ve just posted a new version of the IKEv2 and IPSec T= CP Encapsulation draft. The changes include:

 

- Making the= use case (as a last resort if UDP is blocked) more clear in the introductio= n

- Clarify connection establish= ment and teardown section (allowing a resumed connection to start with eithe= r IKE or ESP traffic, allowing multiple SAs on one TCP connection)

- Adding more details about interactions = with IKEv2 fragmentation, and TCP MSS and QoS markings

<= div>

- Clarifying the keep-alive/DPD section

- A new appendix written by a new author from= Cisco giving four example exchanges with TCP encapsulation of IKEv2.

 

 

I believe this shou= ld address many of the comments the last draft received. Please take a look = and provide your feedback! If the working group is in favor, I’d like = to see if this can be adopted by the working group.

 

Thank= s,

Tommy

 

<= /div>

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

--B_3541669442_1101298664-- --B_3541669442_1434563220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIT8AYJKoZIhvcNAQcCoIIT4TCCE90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggXpMIID0aADAgECAhEAzxzmCopx75U64hFk/UYzGzANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNDExMTAxODMyMTRaFw0xNzExMTAxODMyMTNaMGQxETAPBgNVBAoMCEVyaWNzc29u MRQwEgYDVQQDDAtTYW15IFRvdWF0aTEnMCUGCSqGSIb3DQEJARYYc2FteS50b3VhdGlAZXJp Y3Nzb24uY29tMRAwDgYDVQQFEwdsbWNzYXRvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAtTzHN2e42IspS2LTetBYT1X297J5UERFKNlGu1pG2pcGU/NBSwsizw/RDI/q+c42 EkEAWzJ4usb2oO4//CLw5Foboonf8N2qhwRx5O7gEEIjjSCt2Q7O4mToKM4xoNSTmRrF2war 3mnRc3g0A9T69MD2ipYU3/l7HVnAH4z+95t8FrL/oeFXuc/XgWfBGBSYY6uiyLujAZckgwWV FPN4ZMdGAZJ1AgU8tTLWafREHu3stvWcVniIQoOvJVNLHfYcnW8r/Lh0zaTSDCxusleG+YY3 aKtXGF6CyaxuI8i3GmXWI+LEjNeJUesb/WKnZAubl51efuDJvQ+MDA7dNJaDdQIDAQABo4IB vjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJp Y3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzAB hhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2Eu dHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIwYD VR0RBBwwGoEYc2FteS50b3VhdGlAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGC DwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU rvTqPsDyVm3LeP+8KcedI3WxmhIwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/Szcw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBCT4SQnpZQ7Ur2tRXshjkw2pJJ dHA70enikN4bx2cLmhaRlPfS4/SVEXYMLiTRb58jD0N7/wobI7UAWSRlj5zHn21La1HIE0Mt dsJutSPckZWbguCAl9TgEIGdGIVXKhsanr107KLIyrSu+DwgxOLE5kx6JqgcVV2e3ZockG6s hOGXy1O83yP3muINapuuIdY6qtvPTUJ5zZqNPTCHIDrQLwNx07HVflUkS0G/Ac6W6qdfDnu8 qAE0YAxe1dajdphQK/c3pskR5X7M39t7TlZfnFIxOWco3N7odbZo/8fmjxxvfqtcHa1qBrLr qHz9Itfrn+r5KEMqQG/2WUotU6XuBSuNiDQvLt0VH324IOmlLJpTOG5pWbwIKm0Vz65NcP38 S6Qg3k1XmSYa3Nd/eBDM2S7xsx9gxlxqcGtB0HX7lRFCqNtPd1U7YqPag+fKFgs2rbkrNm9T U0jN95UnrJn0lM4zJgL2Xel2keiuySOQzI9r7NOyaEZXwtnhV3BgcIPZit3D4W6awzI/3HaZ Ub2Cr7HbrHBQAGknGpZZd00a/waLeolL5CvALtUt0KpNz1Jqk5dKGfWLJNNxy2iNFrTThVkU YDEIyyqHLSzxj+W0vq8imtNDvul+8WK/1hCw+XJb9mVb3gpXONrneo5d5oj6SolE/O46eq6+ 2jcfWcwATTCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUA MDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENB IHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3 DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklkoXOgOSBMhW6Fz GVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7sKIyd+LR y4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHkzD0Y F3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBm vEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMG AijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3 T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfF U2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxML WiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiA SHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IB uDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3Qu dGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB /wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8 hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNh djEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYw HQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM 1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblIn oJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDUuzrdANVKnYxh a7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3TpeppQ2yW kyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1tY9i IydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzm iuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0 GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5B up+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XH QYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2 QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TG bTCCBTgwggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4X DTA3MTAxODEyMDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30 N7fl5nx56oy1gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsG Kv7e+ax9g/teuuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF 9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzw rPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQ IBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM 041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6L U7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0 XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1 AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMB Af8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIw DQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG 5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/ yJlr7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD 1RuqWQ65XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uS hXUqXHONbXslkcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMra xIFMu6JzkybI6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq 0Js9cB4kbM2HdqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7 o7i6cEDHJxy/xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsV cUitt+rYWYjUkL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB1TCCAdEC AQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MgIRAM8c5gqKce+VOuIRZP1GMxswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJ BDEWBBRHZCDOlBTdkZUp+IMgJi3SVkxVATAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAzMjQyMDA0MDJaMA0GCSqGSIb3DQEBAQUABIIBAEv7H8KfA7e6 8mO/dhFl/Rot7/pUI9pI1eITSc5YoXr4n6mkE7AB/G/2KEYE/Sx0sEb+xVyeds3gWWzJ/gF6 ILiAS3Hu48tCi2PUYIYcTaSddC83t+hg3F4JVtCMND9vYkWhi+l10KrKGuAHdAMIVWo6TdTR U1pSXlbtyds9flXJtb/gQP+FTepAZrDW4RsVDvRvg3u0JcU72w+kYWFCEoblG3yBacMx+7n+ csdABSbhNsCLJnPtsQDWxtDjZyvYjtBsj5Tmew+/C9mESyhetDb7NWqMqlGOWJ+4Wq4hI4cV jjl/XsUlQ/hZcSb2QPTDLqRakkLUoM6ZWIbf5Uxtj1Q= --B_3541669442_1434563220-- From nobody Sat Mar 26 17:04:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC44C12D1EA for ; Sat, 26 Mar 2016 17:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l8l3ysUxTDnv for ; Sat, 26 Mar 2016 17:04:55 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FC512D188 for ; Sat, 26 Mar 2016 17:04:55 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-b9-56f71df51f86 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F2.A2.30335.5FD17F65; Sun, 27 Mar 2016 00:40:38 +0100 (CET) Received: from EUSAAMB108.ericsson.se ([147.117.188.125]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Sat, 26 Mar 2016 20:04:54 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt Thread-Index: AQHRgUAjXUgsFsLrDEWGERvOk6puAJ9fwSMAgAyzMoA= Date: Sun, 27 Mar 2016 00:04:53 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> In-Reply-To: <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyuXRPgu432e9hBls/M1lsvvKAzWLJx05m i/1bXrBZTGq8xWixu/EPu8XPXdsZLc6tW8BsMfNghsXbT1/YHTg9Wo68ZfVYsuQnk8eaLa+Z ApijuGxSUnMyy1KL9O0SuDJ+nP3JWPBEoOLs/ENMDYxrBLoYOTkkBEwkutfdYoewxSQu3FvP BmILCRxhlNgzwa6LkQvIXs4ocXz2GRaQBJuAkUTboX6gBg4OEQF5iZk3MkFqmAXms0jcnvqD FaRGWCBA4m7DTjBbRCBQ4tF/iAUiAlYSfb/uM4L0sgioSnTtqAUJ8wr4SjQfWcEIsbeFUeL7 miwQm1PAT6J/w3qwtYxAt30/tYYJxGYWEJe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStJzHl9 jRlkFbOApsT6XfoQrYoSU7ofskOsFZQ4OfMJywRGsVlIps5C6JiFpGMWko4FjCyrGDlKiwty ctONDDYxAqPtmASb7g7G+9M9DzEKcDAq8fAWiHwPE2JNLCuuzD3EKMHBrCTCKweMVSHelMTK qtSi/Pii0pzU4kOM0hwsSuK8699eDhMSSE8sSc1OTS1ILYLJMnFwSjUwbulZPvNO9tNr8+eX iD7zP1v5YEJrqJxnRYVulXX+6aDtC6bKOS1ubsq8vPFHauaFg4Utqg/4O3kVjs/uLD7H8Lhk fXHHB8PwTxITjK5vcWoJ0Dfv3czVtn+dwJkNmkGi5z/wqCef6J3hzWulsahn2+eiXRkxCUaC W85wFfTtTbVTaWlyuMyrxFKckWioxVxUnAgAIsPL7LICAAA= Archived-At: Cc: "Nagendran Ramalingam \(Nagendran.Ramalingam@huawei.com\)" , Xufeng Liu , "Wanghonglei \(A\) \(stonewater.wang@huawei.com\)" , "Chenxia \(D\) \(jescia.chenxia@huawei.com\)" , "Wunan \(Eric\) \(eric.wu@huawei.com\)" , Khanh Tran , Ing-Wher Chen , "Lizhenbin \(lizhenbin@huawei.com\)" , "vijay kn \(vijay.kn@huawei.com\)" Subject: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 00:04:57 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBvdXIgZmlyc3QgdmVyc2lvbiBmb3IgdGhlIFlBTkcgbW9kZWwg Zm9yIElLRXYyLiBGZWVsIGZyZWUgdG8gcG9zdCBjb21tZW50cy4gSSB3b3VsZCBiZSBhbHNvIGhh cHB5IHRvIGhhdmUgZmFjZS10by1mYWNlIGRpc2N1c3Npb25zIG9uIHRoZSBkcmFmdCAtIGVzcGVj aWFsbHkgZnJvbSBJS0V2MiBpbXBsZW1lbnRlcnMuDQoNCkJSLCANCkRhbmllbCAgDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBNYXJjaCAxOCwg MjAxNiAxMTowMSBBTQ0KVG86IFhpYSBDaGVuOyBIb25nbGVpIFdhbmc7IEtoYW5oIFRyYW47IEto YW5oIFRyYW47IFZpamF5IEt1bWFyIE5hZ2FyYWo7IERhbmllbCBNaWdhdWx0DQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRyYW4taXBzZWNtZS1pa2V2Mi15YW5n LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10cmFuLWlwc2VjbWUtaWtl djIteWFuZy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2hhbmgg VHJhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC10 cmFuLWlwc2VjbWUtaWtldjIteWFuZw0KUmV2aXNpb246CTAwDQpUaXRsZToJCVlhbmcgRGF0YSBN b2RlbCBmb3IgSUtFdjINCkRvY3VtZW50IGRhdGU6CTIwMTYtMDMtMTgNCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTc2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRyYW4taXBzZWNtZS1pa2V2Mi15YW5nLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXRyYW4taXBzZWNtZS1pa2V2Mi15YW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10cmFuLWlwc2VjbWUtaWtldjIteWFuZy0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQg Y2FuIGJlIHVzZWQgdG8NCiAgIGNvbmZpZ3VyZSBhbmQgbWFuYWdlIEludGVybmV0IEtleSBFeGNo YW5nZSB2ZXJzaW9uIDIgKElLRXYyKS4gIFRoZQ0KICAgbW9kZWwgY292ZXJzIHRoZSBJS0V2MiBw cm90b2NvbCBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBzdGF0ZS4NCg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Mar 27 07:27:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3518D12D116 for ; Sun, 27 Mar 2016 07:27:10 -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 autolearn_force=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 72IbI5bCPLx1 for ; Sun, 27 Mar 2016 07:27:08 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 D8B4412D0C8 for ; Sun, 27 Mar 2016 07:27:08 -0700 (PDT) Received: from [10.32.60.32] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2RER5f8002664 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Mar 2016 07:27:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.32] From: "Paul Hoffman" To: "Tero Kivinen" Date: Sun, 27 Mar 2016 07:27:04 -0700 Message-ID: <2F0A939D-AB06-47F8-A10A-3620A4D44E3D@vpnc.org> In-Reply-To: <22259.1065.700884.653781@fireball.acr.fi> References: <8EE26CB3-8BAB-4942-A209-24016E0BB44C@vpnc.org> <22257.24119.666069.8331@fireball.acr.fi> <9D0439B9FE7946B2B31A75D68279DE84@buildpc> <22259.1065.700884.653781@fireball.acr.fi> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 14:27:10 -0000 On 23 Mar 2016, at 14:01, Tero Kivinen wrote: > Valery Smyslov writes: >>> It matters when you use things like 802.15.9. IEEE 802.15.9 provides a >>> method to transport IKEv2 messages over IEE Std 802.15.4. In typical >>> PHY of the 802.15.4 the max frame size is 127 bytes, which leaves >>> about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2 >>> packet will require about 3-4 fragments sent in 3-4 frames. Each of >>> those frames will be acknowledged, and there might be timing >>> constrains how often they can be sent (for example in TSCH network >>> this might be once per second at max, when using 10ms slot time, and >>> slotframe size of 100). >>> >>> If we raise the MAC size from 8 to 16, that will cause 8% probability >>> that we need one more frame to send that last part... >> >> That's a good reason. Shouldn't this (or similar) explanation be >> added to the draft? > > Perhaps. How much of current information we want to put in the > document. The things are changing all the time, and it might be true > now for IoT, but might not be true in few years. Isn't enough to just > say that currently this algorithm might be used for IoT. That seems to be the right way to go. --Paul Hoffman From nobody Sun Mar 27 10:41:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5912D14A for ; Sun, 27 Mar 2016 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=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 Jw_b4jIAG8A1 for ; Sun, 27 Mar 2016 10:41:42 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 A6AA7127058 for ; Sun, 27 Mar 2016 10:41:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qY48y4dj8zCHb; Sun, 27 Mar 2016 19:41:38 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ca1LLIoRtBp1; Sun, 27 Mar 2016 19:41:37 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 27 Mar 2016 19:41:36 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2EADF61DDE15; Sun, 27 Mar 2016 13:41:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 2EADF61DDE15 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2A8F118D62; Sun, 27 Mar 2016 13:41:36 -0400 (EDT) Date: Sun, 27 Mar 2016 13:41:36 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> Message-ID: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 17:41:44 -0000 On Tue, 22 Mar 2016, Valery Smyslov wrote: > Do I get you right that you want to remove the following text? > > IPv6 networks are > currently a > rarity, so we can only speculate on what their wide deployment will > be like, but the current thinking is that ISP customers will be > assigned whole subnets, so we don't expect the kind of NAT deployment > that is common in IPv4. Yes. Since it is speculative and will quickly go stale in the RFC (we hope :) >> I'm not sure about: >> >> The number of half-open SAs is easy to measure, but it is also >> worthwhile to measure the number of failed IKE_AUTH exchanges. If >> possible, both factors should be taken into account when deciding >> which IP address or prefix is considered suspicious. >> >> I'm not sure what measuring the failed IKE_AUTH exchanges gains you? > > It allows a responder to make a decision whether it is under attack. > If a percentage of IKE_AUTH exchanges that failed to decrypt properly > is high enough, then it means that a large fraction of initiators send bogus > IKE_AUTH requests, so the responder can assume that they > do this for reason. In this case the responder can use puzzles in IKE_AUTH > (see Section 7.2). Ok, although I'm still not convinced doing this won't make the problem worse for the legitimate client. >> Whether or not you accept new work should more depend on your own >> resoures than previously failed attempts, otherwise you risk becoming a > > It is based on both. You must maintain some statistics information > (number of half-open IKE_SA_INIT, number of failed IKE_AUTH) > and make a decision whether to use defensive measures > by analyzing this statistics. I agree on the half-open SA's, I'm not convinced about meassuring failed IKE_AUTH. Previous failures cost no current resources, so I'm not sure if it should be used to as a metric. The metric should be based on current resources, which seem already reflected in the number of half-open SA's you're carrying and the amount of resources those are using. > If you only take into consideration your resources consumption, > then you would end up punishing legitimate clients in case there are so many > of them that you just cannot handle the volume of requests Sure, just like puzzles punish legitimate clients :) > In other words, you must distinguish attack from just a high load. "just a high load" would not have zillions of half-open SA's. > See above. Once you make a decision that an attak is in progress > (e.g. by monitoring the number of failed IKE_AUTH within > last N seconds), you'll turn on IKE_AUTH puzzles or take some other measures. you seem to think you can save the poor legitimate client in a see of botnet. I am not convinced of that. Excluding that, the only thing the server needs to do when under attack is ensure it does not die. So a limit of the half-open SA's make sense _for the server itself_. It's not doing that to help legitimate clients - those have already lost. They are drowned out (with or without a sea of puzzles) >> The cookie mechanism limits the amount of allocated >> state to the size of the bot-net, multiplied by the number of half- >> open SAs allowed per peer address, multiplied by the amount of state >> allocated for each half-open SA. With typical values this can easily >> reach hundreds of megabytes. >> >> It would be clearer to to mention explicitely that the cookie mechanism >> prevents spoofed packets from taking up state, thereby limiting [....] > > Could you please be more explicit what text you are not happy with? I don't think it is obvious enough in the text that cookies prevent attacks based on source IP spoofing, and tHat this attack is based on a network of compromised machines that talk IKE without needing spoofing. I would also just say "attacker" instead of "bot-net" to keep it generic. >> Note that the Responder SHOULD cache >> tickets for a short time to reject reused tickets (Section 4.3.1), >> and therefore there should be no issue of half-open SAs resulting >> from replayed IKE_SESSION_RESUME messages. >> >> I should probably read 5723, but why would one ever respond to an "old" >> re-used or unknown session resume ticket? I guess the only use is a >> faster failure of lost resumption tickets for real clients? Since just >> sending a "go away" response is not more computationally expensive then >> creating a "go away" response for an invalid IKE SPI or badly formed IKE >> packet, I would say it is not worth implementing a separate list of >> recently used tickets. > > RFC 5723 describes two kinds of tickets - "ticket by reference" > and "ticket by value". In the former case the server stores > all the information regarding IKE SAs that can be resumed and the ticket is > just an "index" in that database. With this approach > the server always knows whether the ticket was already used or not. Ok, so that ticket is not covered in the above text. If there is such a ticket, it is unused, not re-used. > With the latter approach all the information regarding the SA > is stored in the ticket itself. The server stores nothing in this case - it > just decrypts the presented ticket and resumes the IKE SA. > In this case the server doesn't know whether the ticket > is used before unless it maintaines a cache of recently > used tickets. Ahh okay. Thanks for the information. That makes sense now. But it does open up another attack. Attackers can flood the responder with bogus resumption tickets, using up the responders CPU. But I see that is covered itself in RFC 5723 section 9.3, but that is currently not references in your current document. Possibly add that for completeness sake? >> If the received IKE_AUTH message failed to decrypt correctly (or >> failed to pass ICV check), then the Responder SHOULD still keep the >> computed SK_* keys, so that if it happened to be an attack, then the >> malicious Initiator cannot get advantage of repeating the attack >> multiple times on a single IKE SA. >> >> Well, it needs to do this anyway in case the attacker is just sending >> bogus responses faster than the real client. So I don't think this > > Do you mean "bogus requests"? Isn't it a DoS attack? Yes I meany bogus IKE_AUTH requests. > >> advise here is warranted - it has nothing to do with ddos. > > I think this advise is closely related to DoS protection. You yourself > described the attack two lines above. It is an (obvious) attack but not a DDOS attack. eg: client IKE_INIT Request ---> <--- IKE_INIT Response server attaker IKE_AUTH Request (bogus) ---> [fails] client IKE_AUTH Request ---> I think any implementor should really already handle this case in general. Any failures of unauthenticated packets must be dropped and the timeout timer continued to wait for the legitimate response. That's a core part of the IKEv2 spec, so I don't think that needs to be repeated in this document. >> To prevent this kind of attacks the responder should not blindly >> download the whole file. Instead it SHOULD first read the initial >> few bytes, decode the length of the ASN.1 structure from these bytes, >> and then download no more than the decoded number of bytes. >> >> That seems really bad. If the attacker controls the URL, they can also >> put an malicious ASN.1 encoding in the cert. Much better is to [Oh never >> mind you write all the things I wrote here already] > > OK. Just to clarify, I do think you need to rewrite the text to not blindly trust the ASN.1 length encoding. Or just remove that advise and stick to the other items to discuss right after. >> With a typical setup and typical Child SA lifetimes, there >> are typically no more than a few such exchanges, often less. >> >> I don't agree. People put in 1s liveness probes, so that's a lot of IKE >> packets. > > Liveness check is about 50 bytes. Even if it is performed > every second, it results in 2 packet/sec and 100 bytes/sec traffic per a > client. Is it a lot? See other discussions. We sadly have a strong demand by operational people to have really short liveness timers. While as implementor, we have refused < 1s, people often do use 1s timers as a way to do High Availability. So I think the advise of limiting the number of allowed responses for an IKE SA in general is dangerous. There are many unexpected use cases. >> Since any endpoint can initiate a new exchange, [...] >> >> I would more explicitely point the AUTH NULL based attacks to its RFC. > > Well, I think we tryed to follow this way: there is little specific to NULL > auth, it is just mentioned (and referenced) as one of the factors that may > make DoS attacks more easy to mount. hmm ok. >> Then focus this document on the possible abuse of legitimate clients. >> However, I don't know what I would want to advise. You can put in >> maximums for rekeys, reauths, or child sa's, but those should at most >> be configuration options, and not hardcoded options in the >> implementation - since implementors cannot predict what legitimate >> large scale use their code might see. > > Sure. And that's why the draft doesn't prescribe any hard limits, > it just lists possible defense measures. right. >> For that reason, it is NOT RECOMMENDED to >> ever increase the IKEv2 window size above its default value of one >> if the peer uses NULL Authentication. >> >> I'm not sure why here the auth method is used to discriminate. Earlier >> it also talked about authenticated clients and launching many exchanges? > > Because with NULL auth the peer is not authenticated and we'd rather limit > him/her abilities to mount DoS attack > by initiating N exchanges in parallel, that would increase > our peak load. If the peer is authenticated, then launching > N exchanges simultaneously is not an attack in general. And if the > authenticated peer mounts such a DoS attack, the > he/she could be traced down and either out-of-band > measures are taken or peer's credentials are revoked. So you are saying basically that this text should have appeared in the AUTH NULL RFC, but didn't. Perhaps then a separate section for AUTH NULL clients could be put in this document, and then also let it update that RFC? >> Also, this advise is actually an update to RFC7619/RFC7296 so this >> document should list it is updating those RFC's. > > Is it really needed? RFC 7296 doesn't deal with NULL auth, > and RFC 7619 does reference this draft in Security Considerations. > What others think of it? I'm curious too what others think this is: a "recommendation" or a "change". >> If the peer initiates too many exchanges of any kind, >> implementations can introduce an artificial delay before >> responding to request messages. This delay would decrease the >> rate the implementation need to process requests from any >> particular peer, making it possible to process requests from the >> others. The delay should not be too long to avoid causing the IKE >> SA to be deleted on the other end due to timeout. >> >> I am not sure how useful this advise is. Since people use liveness >> timeouts of 1s, a malicious peer can always do 1s of exchanges. So if >> you want to introduce delays, they should probably delay only >> non-liveness exchanges. And liveness exchanges that are more frequent >> that 1s should probably just be dropped or rejected. > > It doesn't matter what exchange type is. The intention is to artificially > limit the number of exchanges the malicious peer can initiate per second. See earlier discussion about 1s liveness probes.... It is very common. > There is a MID window, so the peer cannot initiate a new exchange until > one of the currently active exchanges is completed. If, for example, > window size is 1, then the malcious peer cannot initiate a new > exchange until we send a responce to the current one. If we send > response immediately, then the malicious peer immediately > initiates another exchange. If we respond in 3 seconds, then it will have to > wait 3 seconds, before it can initiate a new exchange Yes, I don't have a problem with this part. > (probably sending retransmissions during that time that we will ignore). > That's an idea. If malicious peer is so impatient, that it'll tear down the > IKE SA if no response is received within 3 seconds, then it'll make worse for > itself - it'll need to create > a new IKE SA from scratch passing all the puzzles barriers. Sure. >> Note, that if the Responder >> receives retransmissions of the request message during the delay >> period, the retransmitted messages should be silently discarded. >> >> That also updated RFC-7296 which states that each IKE request should get >> an IKE answer. > > I don't think artificaial delay is a violation of RFC 7296. > Each IKE request will be answered. RFC 7296 doesn't require that > it is answered immediately (or as soon as responder can prepare the > response). Yes, you are right. Strike this remark :) >> While the document mentions Fragmentation with respect to puzzles, it >> does not mention ddos attacks based on malicious fragmentation packets. >> It could be that the base RFC is clear enough, but perhaps this document >> should give some advise too? > > I think RFC 7383 lists possible DoS attacks in Security Considerations > section. > Do you think it's not enough? It is, but you are inconsistent with what you pull it or reference from other RFC's? See above discussion. btw. thanks for this discussion. It has raised some interesting implementation details, some of which I now want to implement :) Paul From nobody Mon Mar 28 07:06:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD5012D982 for ; Mon, 28 Mar 2016 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BbONzLpQaXYK for ; Mon, 28 Mar 2016 07:06:03 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A02712D98C for ; Mon, 28 Mar 2016 07:06:01 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id f67so39000018lfb.0 for ; Mon, 28 Mar 2016 07:06:01 -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-transfer-encoding; bh=hNsqEUpkRUqPcvfoxRq2zJBCGs+NQqmMFOBLn4gKub4=; b=Nd6PbVqanMRQp5HX2LfKVjNsiKeWETFlw5m4rK7ncM4AEJov4Q40osw5+LSURihnGQ D40NIpRMJCvU7vW1vBKHSDCT/P+8US9jHojfgncMsHrwubKW4TotYUrpmmDdqBuO/nfo RlD2yNtnY2LK3irEArCUaTB3AJOgV3BCeIXaf0WbcRygedy8kHV/J1HHhnWK/V9UjorG SMvmQZgrlUmczPzJtjtkjQknUrIqLY6cD22BP0PtIo/Gq6SMLYLSrp6CRZaqoNv+187l Ikdnj2x7T0we3lPunFjUAvLMLyBdHlgB1SQyRqTYXLP8quZ94zai+KApVIax7VsB1wAn vZRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=hNsqEUpkRUqPcvfoxRq2zJBCGs+NQqmMFOBLn4gKub4=; b=YOcTcY1SizDpzNP7jqNZMyfew2Udtg6oTQHIMk3suoBWRcMk5kpe3bb0bCYtLEcFyH DM3tYcsf5kqAeo5oh8VZ4bmaU/g+N1ui56vponFnciRNdNVcUvBwZBL17zgwGSP8jc1L NxTGEFe6kdFbZg09e8JIdRQo6JxCo3Yr6DtWx0XDAgaKwKVRGRDJuJqpsrh7jRwpozw2 0DehzaqOq0XpPO4qr/qaoI9PrEtaomkTetZi7PM/mGWstLgJfBqEtjv5gjytFIghjSVO k8vmcPphUu0ybGftUiu/t1aRPNI8cm7J/PC8fSR/2P+SqOLon9N3RHc1KdHy/DzVSb7T SraQ== X-Gm-Message-State: AD7BkJLZHgPTES5O5zr1r+2YsxUM4Mw+urHdvb3748ufdqzRI7f/J7lE5D8UVHzd6WtmLw== X-Received: by 10.25.21.166 with SMTP id 38mr4206751lfv.160.1459173959774; Mon, 28 Mar 2016 07:05:59 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o81sm4377152lfb.44.2016.03.28.07.05.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 07:05:58 -0700 (PDT) Message-ID: <22A743E8E50E402EBD698E354719C11C@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> Date: Mon, 28 Mar 2016 17:05:55 +0300 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: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:06:06 -0000 Hi Paul, >> Do I get you right that you want to remove the following text? >> >> IPv6 networks are >> currently a >> rarity, so we can only speculate on what their wide deployment will >> be like, but the current thinking is that ISP customers will be >> assigned whole subnets, so we don't expect the kind of NAT deployment >> that is common in IPv4. > > Yes. Since it is speculative and will quickly go stale in the RFC (we hope :) OK. >> It is based on both. You must maintain some statistics information >> (number of half-open IKE_SA_INIT, number of failed IKE_AUTH) >> and make a decision whether to use defensive measures >> by analyzing this statistics. > > I agree on the half-open SA's, I'm not convinced about meassuring failed > IKE_AUTH. Previous failures cost no current resources, so I'm not sure > if it should be used to as a metric. The metric should be based on > current resources, which seem already reflected in the number of > half-open SA's you're carrying and the amount of resources those are > using. You are right that once an attacker sent bogus IKE_AUTH request and the responder spent some CPU resources to calculate the DH to only recognize that it cannot decrypt the message, nothing can be done since the responder has already spent that resources. However, let's look on a wider picture. The goal of attacker is to exhaust responder's CPU power (not the memory like in half-open SAs), so the attacker would initiate zillions of fake IKE SAs to send bogus IKE_AUTH request on each of them. Only in this case the attack will be successful. But since the responder's CPU most likely doesn't have zillions cores, the processing of all these SAs will be done in sequence and will take some time. If during that time the responder measures the percentage of bogus IKE_AUTH requests it can detect that the attack is most likely in progress and turn on IKE_AUTH puzzles. So few millions of that zillions bogus IKE_AUTH requests would pass before the defense is activated, however the others will be thwarted. >> In other words, you must distinguish attack from just a high load. > > "just a high load" would not have zillions of half-open SA's. Sure. And would not have zillions of bogus IKE_AUTH requests. That's why it is not sufficient to measure only load. If the responder cannot tolerate the load caused solely by legitimate users (no half-open SAs, no bogus IKE_AUTH requests, just too many initiators), then you'd better replace it with the more powerfull one than to punish the users. >> See above. Once you make a decision that an attak is in progress >> (e.g. by monitoring the number of failed IKE_AUTH within >> last N seconds), you'll turn on IKE_AUTH puzzles or take some other measures. > > you seem to think you can save the poor legitimate client in a see of > botnet. By all means. Otherwise we would fail completely. I agree that in case of attack the legitimate clients would suffer, however the server shoul do its best to allow them to work. > I am not convinced of that. Excluding that, the only thing the > server needs to do when under attack is ensure it does not die. No. It should continue to serve legitimate clients (at least try to do it). > So a limit of the half-open SA's make sense _for the server itself_. It's not > doing that to help legitimate clients - those have already lost. They > are drowned out (with or without a sea of puzzles) The liveness of the server is not a goal per se. If it were the goal then there would be a simple and perfect DDoS defense - just unplug network cable. The server will be alive forever, however it won't provide the service, so the _Denial_of_Service_ attack will be successful. We don't want that kind of defense. >>> The cookie mechanism limits the amount of allocated >>> state to the size of the bot-net, multiplied by the number of half- >>> open SAs allowed per peer address, multiplied by the amount of state >>> allocated for each half-open SA. With typical values this can easily >>> reach hundreds of megabytes. >>> >>> It would be clearer to to mention explicitely that the cookie mechanism >>> prevents spoofed packets from taking up state, thereby limiting [....] >> >> Could you please be more explicit what text you are not happy with? > > I don't think it is obvious enough in the text that cookies prevent > attacks based on source IP spoofing, and tHat this attack is based on > a network of compromised machines that talk IKE without needing > spoofing. I would also just say "attacker" instead of "bot-net" to keep > it generic. OK. >> With the latter approach all the information regarding the SA >> is stored in the ticket itself. The server stores nothing in this case - it >> just decrypts the presented ticket and resumes the IKE SA. >> In this case the server doesn't know whether the ticket >> is used before unless it maintaines a cache of recently >> used tickets. > > Ahh okay. Thanks for the information. That makes sense now. But it does > open up another attack. Attackers can flood the responder with bogus > resumption tickets, using up the responders CPU. But I see that is covered > itself in RFC 5723 section 9.3, but that is currently not references in > your current document. Possibly add that for completeness sake? OK. >>> advise here is warranted - it has nothing to do with ddos. >> >> I think this advise is closely related to DoS protection. You yourself >> described the attack two lines above. > > It is an (obvious) attack but not a DDOS attack. eg: > > client IKE_INIT Request ---> > <--- IKE_INIT Response server > attaker IKE_AUTH Request (bogus) ---> [fails] > client IKE_AUTH Request ---> > > I think any implementor should really already handle this case in > general. Any failures of unauthenticated packets must be dropped > and the timeout timer continued to wait for the legitimate response. > That's a core part of the IKEv2 spec, so I don't think that needs > to be repeated in this document. The text is not exactly about this. Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED and SK_* keys. However, it is a good idea not to do it immeditely, but instead wait for the IKE_AUTH request to come. The reason is that in case IKE_AUTH request never came (attack, network problem etc.), the responder would not spent quite a lot of CPU resources calculating D-H shared secret. However, in this case careless implementations could discard the just computed SK_* keys if the IKE_AUTH request failes to decrypt. This is wrong, because these key depend only in the information from IKE_SA_INIT and there is no reason to discard them once they are computed. The text just emphasize this idea. > Just to clarify, I do think you need to rewrite the text to not blindly > trust the ASN.1 length encoding. Or just remove that advise and stick > to the other items to discuss right after. OK. >> Liveness check is about 50 bytes. Even if it is performed >> every second, it results in 2 packet/sec and 100 bytes/sec traffic per a >> client. Is it a lot? > > See other discussions. We sadly have a strong demand by operational > people to have really short liveness timers. While as implementor, we > have refused < 1s, people often do use 1s timers as a way to do High > Availability. So I think the advise of limiting the number of allowed > responses for an IKE SA in general is dangerous. There are many > unexpected use cases. No, there is no advises to limit the number of responses. There is an advice to delay responce in case of there are too many requests in order to limit the rate of requests. If your implementation relies on an immediate reply and no packets loss, then don't follow this advice. However, I think that if implementations cannot tolerate 2-3 sec delay to requests, then they cannot operate reliably. >> Because with NULL auth the peer is not authenticated and we'd rather limit >> him/her abilities to mount DoS attack >> by initiating N exchanges in parallel, that would increase >> our peak load. If the peer is authenticated, then launching >> N exchanges simultaneously is not an attack in general. And if the >> authenticated peer mounts such a DoS attack, the >> he/she could be traced down and either out-of-band >> measures are taken or peer's credentials are revoked. > > So you are saying basically that this text should have appeared in the > AUTH NULL RFC, but didn't. The more general text was included there (Section 3.2), and you were the author :-) > Perhaps then a separate section for AUTH NULL > clients could be put in this document, and then also let it update that > RFC? I don't think the update is needed. RFC 7619 has already referenced this document (as a draft) and has warnings that NULL auth clients are unauthenticated and thus can mount various attacks. >> Is it really needed? RFC 7296 doesn't deal with NULL auth, >> and RFC 7619 does reference this draft in Security Considerations. >> What others think of it? > > I'm curious too what others think this is: a "recommendation" or a "change". I think it is a recommendation. >> It doesn't matter what exchange type is. The intention is to artificially >> limit the number of exchanges the malicious peer can initiate per second. > > See earlier discussion about 1s liveness probes.... It is very common. As I said above you can ignore this recommendation if your implementation so deeply relies on quick response. >> I don't think artificaial delay is a violation of RFC 7296. >> Each IKE request will be answered. RFC 7296 doesn't require that >> it is answered immediately (or as soon as responder can prepare the >> response). > > Yes, you are right. Strike this remark :) OK. >>> While the document mentions Fragmentation with respect to puzzles, it >>> does not mention ddos attacks based on malicious fragmentation packets. >>> It could be that the base RFC is clear enough, but perhaps this document >>> should give some advise too? >> >> I think RFC 7383 lists possible DoS attacks in Security Considerations >> section. >> Do you think it's not enough? > > It is, but you are inconsistent with what you pull it or reference from > other RFC's? See above discussion. OK. > btw. thanks for this discussion. It has raised some interesting > implementation details, some of which I now want to implement :) Thank you :-) > Paul Regards, Valery. From nobody Mon Mar 28 07:29:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268012D9D3 for ; Mon, 28 Mar 2016 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=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 I4uUCyjJjnu6 for ; Mon, 28 Mar 2016 07:29:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7F9AE12D9DC for ; Mon, 28 Mar 2016 07:29:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qYbrY5cmqzCJn; Mon, 28 Mar 2016 16:29:17 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LCzoEpcYcN7t; Mon, 28 Mar 2016 16:29:16 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 28 Mar 2016 16:29:16 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 77F8960007EA; Mon, 28 Mar 2016 10:29:15 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 77F8960007EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7479F18D6F; Mon, 28 Mar 2016 10:29:15 -0400 (EDT) Date: Mon, 28 Mar 2016 10:29:15 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> Message-ID: References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:29:53 -0000 On Sun, 27 Mar 2016, Daniel Migault wrote: > Subject: [IPsec] FW: New Version Notification for > draft-tran-ipsecme-ikev2-yang-00.txt > Please find our first version for the YANG model for IKEv2. Feel free > to post comments. I would be also happy to have face-to-face > discussions on the draft - especially from IKEv2 implementers. Might be good for me to have a talk about it, especially because I'm not a yang person. . I'm still a bit confused about the syntax. There is code in the document that looks like "ready to use" but also looks like "example to use". like: description "This YANG module defines the configuration and operational state data for Internet Key Exchange version 2 (IKEv2) on IETF draft. Copyright (c) 2016 Ericsson AB. All rights reserved."; All rights reserved? huh? Is that an example? or is this an error? I'm confused about units too, like: leaf initial-retransmission-timeout { type uint32; description "initial retransmission timeout value"; } look weird to me. What's the unit here? uint32 is not a unit, it is a number Is this seconds? miliseconds? seconds since 1970? Since 1772? Some of it looks like just copying IANA registries? So that would be outdated quickly. How would that get updated? Should we really put chunks of code in RFCs like that? Paul From nobody Mon Mar 28 08:00:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6512DA86 for ; Mon, 28 Mar 2016 08:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=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 12uWQqg5Ppyh for ; Mon, 28 Mar 2016 08:00:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 AB5E812DAAB for ; Mon, 28 Mar 2016 07:57:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qYcTZ6t2bzCJn; Mon, 28 Mar 2016 16:57:54 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GbAMvMnQnhQm; Mon, 28 Mar 2016 16:57:54 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 28 Mar 2016 16:57:53 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 09DF760007EA; Mon, 28 Mar 2016 10:57:53 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 09DF760007EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 051B218D6F; Mon, 28 Mar 2016 10:57:53 -0400 (EDT) Date: Mon, 28 Mar 2016 10:57:52 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <22A743E8E50E402EBD698E354719C11C@buildpc> Message-ID: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> <22A743E8E50E402EBD698E354719C11C@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 15:00:03 -0000 On Mon, 28 Mar 2016, Valery Smyslov wrote: [ cutting a bunch of text since we seem to just disagree about whether puzzles are harmful or helpful ] >> It is an (obvious) attack but not a DDOS attack. eg: >> >> client IKE_INIT Request ---> >> <--- IKE_INIT Response server >> attaker IKE_AUTH Request (bogus) ---> [fails] >> client IKE_AUTH Request ---> >> >> I think any implementor should really already handle this case in >> general. Any failures of unauthenticated packets must be dropped >> and the timeout timer continued to wait for the legitimate response. >> That's a core part of the IKEv2 spec, so I don't think that needs >> to be repeated in this document. > > The text is not exactly about this. > Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED > and SK_* keys. However, it is a good > idea not to do it immeditely, but instead wait for the IKE_AUTH request to > come. > The reason is that in case IKE_AUTH request never came (attack, network > problem etc.), the responder would not spent quite a lot of CPU resources > calculating D-H shared secret. If we assume cookies take care of spoofed IPs, then an attacker trying to waste the responders resources would exchange an IKE_INIT round, and then just send a bunch of IKE_AUTH packets (with proper SPIs) that all will fail to decrypt. The responder has to try all of them because it could be a legitimate client. So I'm not sure if you actually buy anything by postponing the SKEYSEED and SK_* calculation? > However, in this case careless implementations could > discard the just computed SK_* keys if the IKE_AUTH request failes to > decrypt. Like I said, that would be _really_ stupid. So stupid that I don't think it needs to go into an RFC. As you have to protect against the attack I list above anyway. >> See other discussions. We sadly have a strong demand by operational >> people to have really short liveness timers. While as implementor, we >> have refused < 1s, people often do use 1s timers as a way to do High >> Availability. So I think the advise of limiting the number of allowed >> responses for an IKE SA in general is dangerous. There are many >> unexpected use cases. > > No, there is no advises to limit the number of responses. > There is an advice to delay responce in case of there are too > many requests in order to limit the rate of requests. If your implementation > relies on an immediate reply and no packets loss, then don't follow this > advice. Can you at least put in a small note on the issue of liveness probes and the risk of delaying these? Eg a 3 probe, 1s each liveness would die in 3 seconds, which seems to be well within the range in which you say implementations could delay things. > However, I think that if implementations cannot tolerate > 2-3 sec delay to requests, then they cannot operate reliably. I've had long frustrating discussions with Large Clients that run things that need to failover/restart within seconds, using very flaky third world networking, and insisting on liveness timers of 1s. It happens :/ Apparently, it is more reliable for them to restart than to wait 30 seconds. >> So you are saying basically that this text should have appeared in the >> AUTH NULL RFC, but didn't. > > The more general text was included there (Section 3.2), and you were the > author :-) Oh, I am very fallible :) >> Perhaps then a separate section for AUTH NULL >> clients could be put in this document, and then also let it update that >> RFC? > > I don't think the update is needed. RFC 7619 has already referenced > this document (as a draft) and has warnings that NULL auth > clients are unauthenticated and thus can mount various attacks. Ohh, you are right. it does reference it already. Still, putting the "updates" in might work because it will cause an "updated by" clause to appear at the top of 7619, so people are more convinced they need to also read this document. But I'll let the chairs weight in on this. Paul From nobody Mon Mar 28 08:06:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88612DB09 for ; Mon, 28 Mar 2016 08:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 ZZpa94sdZsqH for ; Mon, 28 Mar 2016 08:06:39 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id BD52812DA95 for ; Mon, 28 Mar 2016 08:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 5B34D3F842; Mon, 28 Mar 2016 17:03:29 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CvPLWEpiPsIF; Mon, 28 Mar 2016 17:03:29 +0200 (CEST) Received: from [192.168.1.3] (106.Red-81-36-109.dynamicIP.rima-tde.net [81.36.109.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon21.um.es (Postfix) with ESMTPSA id 40F2C3F92B; Mon, 28 Mar 2016 17:03:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A648F1C7-60F3-4A19-8A20-2371639759C2"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Gabriel Lopez In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> Date: Mon, 28 Mar 2016 17:03:16 +0200 Message-Id: References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> To: Daniel Migault X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Nagendran Ramalingam \(Nagendran.Ramalingam@huawei.com\)" , Xufeng Liu , IPsecME WG , "Wanghonglei \(A\) \(stonewater.wang@huawei.com\)" , "Chenxia \(D\) \(jescia.chenxia@huawei.com\)" , "Wunan \(Eric\) \(eric.wu@huawei.com\)" , Khanh Tran , Ing-Wher Chen , "Lizhenbin \(lizhenbin@huawei.com\)" , "vijay kn \(vijay.kn@huawei.com\)" Subject: Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 15:06:47 -0000 --Apple-Mail=_A648F1C7-60F3-4A19-8A20-2371639759C2 Content-Type: multipart/alternative; boundary="Apple-Mail=_783835EE-7004-4A32-8014-9D5E115727F2" --Apple-Mail=_783835EE-7004-4A32-8014-9D5E115727F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Documents draft-tran-ipsecme-yang-01 and = draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date = (2016-03-18) and most of the authors coincide. Both documents describe a = Yang IKEv2 configuration data model. The latter is focused on IKEv2, the = former includes IPSec and IKEv1 data models. Sorry, I=E2=80=99m a bit confused, what is the right document to check = the IKEv2 yang model? In both cases, it would be useful to include examples for basic = IPSec/IKE scenarios. Regards, Gabi. > El 27 mar 2016, a las 1:04, Daniel Migault = escribi=C3=B3: >=20 > Hi, >=20 > Please find our first version for the YANG model for IKEv2. Feel free = to post comments. I would be also happy to have face-to-face discussions = on the draft - especially from IKEv2 implementers. >=20 > BR, > Daniel >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, March 18, 2016 11:01 AM > To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar = Nagaraj; Daniel Migault > Subject: New Version Notification for = draft-tran-ipsecme-ikev2-yang-00.txt >=20 >=20 > A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt > has been successfully submitted by Khanh Tran and posted to the IETF = repository. >=20 > Name: draft-tran-ipsecme-ikev2-yang > Revision: 00 > Title: Yang Data Model for IKEv2 > Document date: 2016-03-18 > Group: Individual Submission > Pages: 76 > URL: = https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt > Status: = https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/ > Htmlized: = https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00 >=20 >=20 > Abstract: > This document defines a YANG data model that can be used to > configure and manage Internet Key Exchange version 2 (IKEv2). The > model covers the IKEv2 protocol configuration and operational state. >=20 >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_783835EE-7004-4A32-8014-9D5E115727F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi,

Documents draft-tran-ipsecme-yang-01 and = draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date = (2016-03-18) and most of the authors coincide. Both documents describe a = Yang IKEv2 configuration data model. The latter is focused on IKEv2, the = former includes IPSec and IKEv1 data models.

Sorry, I=E2=80=99m a bit confused, what = is the right document to check the IKEv2 yang model?

In both cases, it would = be useful to include examples for basic IPSec/IKE scenarios.

Regards, Gabi.


El 27 mar 2016, a las 1:04, = Daniel Migault <daniel.migault@ericsson.com> escribi=C3=B3:

Hi, =

Please find our first version for the YANG = model for IKEv2. Feel free to post comments. I would be also happy to = have face-to-face discussions on the draft - especially from IKEv2 = implementers.

BR,
Daniel =  

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Friday, March 18, 2016 11:01 AM
To: Xia Chen; Honglei = Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj; Daniel Migault
Subject: New Version Notification for = draft-tran-ipsecme-ikev2-yang-00.txt


A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt
has been successfully submitted by Khanh Tran and posted to = the IETF repository.

Name: = draft-tran-ipsecme-ikev2-yang
Revision: 00
Title:= = Yang Data Model for IKEv2
Document date: = 2016-03-18
Group: Individual Submission
Pages:= = 76
URL: =            https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-y= ang-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/=
Htmlized:       https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00


Abstract:
=   This document defines a YANG data model that can be used = to
  configure and manage Internet Key Exchange = version 2 (IKEv2).  The
  model covers the = IKEv2 protocol configuration and operational state.





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

The IETF Secretariat

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_783835EE-7004-4A32-8014-9D5E115727F2-- --Apple-Mail=_A648F1C7-60F3-4A19-8A20-2371639759C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW+Ue1AAoJEMUYqoSNEZFT+S4H/iE6gdz7ZS0/tcJN6kMVU+8q 6KWVpl2ZWvE3Qit+JA8ZuBgZFrYJmJg9/SaNNpYAVZx31h+I2sivMDVvW36QXqHI 22qhu9EtYkIQfWMuKEv1rgxD4BbZSeXiGm8tZ5DiIzWuFfw/63NWjz3kUV5QffMv AXJCIbCWum45fdpaHNzREAW7wTaiVuHcGPuhc+fkfJvLOp2RsHWvHosJOscuuKGU s469PLWWEUuz5zIcA73T5SYKvl+V9lIDGNSfG8NR3eW8Kqq6g9KImifvMcdhEYhZ Ao5kYVIopaLY4GHkuof8zFFWcwu/3aUTTpxyQNBdnjiwY2pFf41f7zHqC++C5rU= =Fp6B -----END PGP SIGNATURE----- --Apple-Mail=_A648F1C7-60F3-4A19-8A20-2371639759C2-- From nobody Mon Mar 28 08:21:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4312DAA0 for ; Mon, 28 Mar 2016 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lB_-IlxRnaQj for ; Mon, 28 Mar 2016 08:21:41 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC44712D966 for ; Mon, 28 Mar 2016 08:19:37 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id vo2so31033411lbb.1 for ; Mon, 28 Mar 2016 08:19:37 -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-transfer-encoding; bh=ejEk2/xj293O+MRwnqKwjUERoVCGMKIH/mGg6DEQ8PA=; b=xVTZbbCfa1GanMRZO0+Kzf6Rpq5WwryIM1+w7P8buVgg96jHyoeEm5se3mWnt0efNf xOVBA1FMw70G7GdxpLwcX609DsbXFZMfgy9fiBGghe4FVO7ydrl/UfuhAZgLJZvVTzVq xn1670or0VS/y6dE1G/iJXA+Zj6pWAVrxTafdXblWZBfvTmT/7NP0jOTNbL7YhszqVVw E5XRzPLI18yxGwvwtliLdoiDdrrU1rOCn269092+NCaOcM1ZD3+DLUBVPtEzpgcvbelI 6axSIEv/CEBTyxu1I+ILBDoejVTf+JlYkt6s31pMoU8r7BThh+O+VLbjpzIXQ/jk5Kq+ zngA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=ejEk2/xj293O+MRwnqKwjUERoVCGMKIH/mGg6DEQ8PA=; b=gHvdFFdPUNLs5YDdZ0J1bxx1FsIakGVdA8ZpfURYaDg/GpV0ial88RSItiC0r+uPeF df6+a9CnqeCy1WkQyPnt5RzbxV2eADm+v9TAUhe5SHcNlxLM7Xh9A+v8DIiOfWTZRbLM IdM4ohJzfi8A+//1vT2AqzcxlLINGts+3jnx234Nw3TMyYFOJyBPBWxcYwO3qn/+VpaM t60S5otvlKQR8lPbZR+S3dSBU5cfJfPYrqwiokLaLJqes22CW0qz2KxJwdaTg+Wo/FQ3 /wYaUsuXMg8sGJRtfOWi6aKHP2m8BBSg5nFghj24ADERCXwk0ome3kX/FYBOOxYHV0r0 09gQ== X-Gm-Message-State: AD7BkJJAwalGjQKWxsReYWOwF6ZBtL4oTFenX6VMKclgBvs+AiwlsIWKNKHjOlH0SbQacQ== X-Received: by 10.112.125.201 with SMTP id ms9mr10407209lbb.141.1459178376000; Mon, 28 Mar 2016 08:19:36 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i2sm4504162lfd.43.2016.03.28.08.19.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 08:19:35 -0700 (PDT) Message-ID: <8D8EBD80E21449B0838FA6562F195411@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> <22A743E8E50E402EBD698E354719C11C@buildpc> Date: Mon, 28 Mar 2016 18:19:30 +0300 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: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 15:21:43 -0000 >> The text is not exactly about this. >> Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED >> and SK_* keys. However, it is a good >> idea not to do it immeditely, but instead wait for the IKE_AUTH request to >> come. >> The reason is that in case IKE_AUTH request never came (attack, network >> problem etc.), the responder would not spent quite a lot of CPU resources >> calculating D-H shared secret. > > If we assume cookies take care of spoofed IPs, then an attacker trying > to waste the responders resources would exchange an IKE_INIT round, > and then just send a bunch of IKE_AUTH packets (with proper SPIs) that > all will fail to decrypt. The responder has to try all of them because > it could be a legitimate client. So I'm not sure if you actually buy > anything by postponing the SKEYSEED and SK_* calculation? Postponing SKEYSEED and SK_* calculation saves your resources if IKE_AUTH request never come. It can be if there are some network problems (for example, the IKE_AUTH message is too long, get fragmented by IP and dropped by NAT, and the initiator doesn't support IKE fragmentation) or if the initiator never mind to send IKE_AUTH (i.e. it is an attack on half-open SAs, that could be even with cookies - in case of botnets). >> However, in this case careless implementations could >> discard the just computed SK_* keys if the IKE_AUTH request failes to >> decrypt. > > Like I said, that would be _really_ stupid. So stupid that I don't think > it needs to go into an RFC. As you have to protect against the attack > I list above anyway. Mostly yes. However in some cases it is not so stupid. If you do all crypto in hardware and this hardware may handle limited number of key handles, then you'd probably discard the keys in this case not to exhaust crypto HW memory. In this case you'll recalculate them once new IKE_AUTH arrives. This a tradeoff and the draft recommends (with SHOULD) to keep the keys. >>> See other discussions. We sadly have a strong demand by operational >>> people to have really short liveness timers. While as implementor, we >>> have refused < 1s, people often do use 1s timers as a way to do High >>> Availability. So I think the advise of limiting the number of allowed >>> responses for an IKE SA in general is dangerous. There are many >>> unexpected use cases. >> >> No, there is no advises to limit the number of responses. >> There is an advice to delay responce in case of there are too >> many requests in order to limit the rate of requests. If your implementation >> relies on an immediate reply and no packets loss, then don't follow this >> advice. > > Can you at least put in a small note on the issue of liveness probes and > the risk of delaying these? Eg a 3 probe, 1s each liveness would die in > 3 seconds, which seems to be well within the range in which you say > implementations could delay things. OK. Regards, Valery. From nobody Mon Mar 28 08:26:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5D212DA8F for ; Mon, 28 Mar 2016 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=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 oYrUjaY7Jln9 for ; Mon, 28 Mar 2016 08:26:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5578512DA86 for ; Mon, 28 Mar 2016 08:26:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qYd6j5SlYzCZC; Mon, 28 Mar 2016 17:26:37 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id mHmPKXjt89cA; Mon, 28 Mar 2016 17:26:36 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 28 Mar 2016 17:26:36 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1E47B60007EA; Mon, 28 Mar 2016 11:26:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1E47B60007EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1A10818D6F; Mon, 28 Mar 2016 11:26:36 -0400 (EDT) Date: Mon, 28 Mar 2016 11:26:36 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <8D8EBD80E21449B0838FA6562F195411@buildpc> Message-ID: References: <20160321201328.12185.28466.idtracker@ietfa.amsl.com> <3A97CB619AEA41FE9EE901AF4FAF45CA@buildpc> <22A743E8E50E402EBD698E354719C11C@buildpc> <8D8EBD80E21449B0838FA6562F195411@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 15:26:41 -0000 On Mon, 28 Mar 2016, Valery Smyslov wrote: >> If we assume cookies take care of spoofed IPs, then an attacker trying >> to waste the responders resources would exchange an IKE_INIT round, >> and then just send a bunch of IKE_AUTH packets (with proper SPIs) that >> all will fail to decrypt. The responder has to try all of them because >> it could be a legitimate client. So I'm not sure if you actually buy >> anything by postponing the SKEYSEED and SK_* calculation? > > Postponing SKEYSEED and SK_* calculation saves your resources > if IKE_AUTH request never come. But if the attacker wants to exhaust your cpu, they _will_ come back with a /dev/random filled IKE_AUTH request. > It can be if there are some network > problems (for example, the IKE_AUTH message is too long, get fragmented > by IP and dropped by NAT, and the initiator doesn't support IKE > fragmentation) > or if the initiator never mind to send IKE_AUTH (i.e. it is an attack on > half-open SAs, that could be even with cookies - in case of botnets). That's not really a ddos protection. It's more of a common sense thing. > Mostly yes. However in some cases it is not so stupid. If you do all crypto > in hardware > and this hardware may handle limited number of key handles, then > you'd probably discard the keys in this case not to exhaust crypto HW memory. > In this case you'll recalculate them once new IKE_AUTH arrives. > This a tradeoff and the draft recommends (with SHOULD) to keep the keys. Ok, I guess I feel it is a bit of a stretch away from "ddos defense" and more of a "core implementation sanity", but I guess that line is a little subjective, and I guess a paragraph extra won't hurt the document. Paul From nobody Mon Mar 28 13:43:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53312DB1C for ; Mon, 28 Mar 2016 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qW_o62Nox3cC for ; Mon, 28 Mar 2016 13:43:55 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9EC12D179 for ; Mon, 28 Mar 2016 13:43:55 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id p65so111756644wmp.0 for ; Mon, 28 Mar 2016 13:43:55 -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:date:message-id:subject :from:to:cc; bh=o5c1IoJiRpDqirNIFJrSkdp4WozDozXQMHlv1t+ihsA=; b=J8QwwnPbp7v0gKUzr3Yyh0kmkSUTTAMUHoAFeIU0ByokP5ab/LWBh+T/y+JVeC30Bg hehffTD0tKTc6yXiHXyLm0LpRUaKGyGXEMrfz+QA0s3EEph4ITvquoseR5Mux27QhD0n XfF2iIjcVQYa/1OyOoX+ml8IG9jR0R4nMHA8xjZicXPYSZ/dxzP9nSJfsxaRfF3/ggI1 y+5D5ryEyW5auU6xvUAfSD5Lh9l+WLsA24NPTtgVoPxNcvALRwNHPwM1HXMJr6XPTcJ3 2QayEp3vn4Mmtrz4nYDPkEouRbzhHJAVPsMiYQyjvvLNXEVUcPe6xjEje/v+5FPct7lR j/MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o5c1IoJiRpDqirNIFJrSkdp4WozDozXQMHlv1t+ihsA=; b=MhaRfReR0Pxanrdg/MPK54Gfc3QW7j62iyfV/KWlMOrwUZ83+/9JSvgcVgRB3djhti LcP5xNmhWPSUfajpwF3UkbziM8MxtDHtIcnUTyKeZNL15QmCbizf2s8txcHNUGp+AkOJ IU4ejOLUs8qUDVHT1gHqXuu/sEGLeVGNc1gBIQyHuiIdvIwVfwKxRepvXr3mGj+gR2ib sOwzQwZ6DHbC1I5g3Spfe4rm7fGIqsuNgOowjqz4cGmJRkpP5sFS1iB0+PlT8y3V/YrO W+3Auaj9RErx4RZlbGr018vdtmT2dgN2UVCrjLIMkfug5Prna2GZaD+IuvGxsb/bQTNa lL8A== X-Gm-Message-State: AD7BkJJXdMMpxbxaAz+aHLde7lfS5Sg/5gPBsd0y+rl0kODhfuIRT7gpuU7U8sbMJlwkdPNzsl6dfoUWZbK49A== MIME-Version: 1.0 X-Received: by 10.194.3.110 with SMTP id b14mr30427869wjb.116.1459197833614; Mon, 28 Mar 2016 13:43:53 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.171 with HTTP; Mon, 28 Mar 2016 13:43:53 -0700 (PDT) In-Reply-To: References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> Date: Mon, 28 Mar 2016 17:43:53 -0300 X-Google-Sender-Auth: 65qWWWP4wYP627lTxZNHBgEcR0Q Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7b33dc50879e01052f21f8dd Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 20:43:57 -0000 --047d7b33dc50879e01052f21f8dd Content-Type: text/plain; charset=UTF-8 Hi Paul, I leave my co-authors to respond on the YANG aspects. Regarding the initial-retransmission-timeout I think we meant a time in second. Do you think we need more options? BR, Daniel On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters wrote: > On Sun, 27 Mar 2016, Daniel Migault wrote: > > Subject: [IPsec] FW: New Version Notification for >> draft-tran-ipsecme-ikev2-yang-00.txt >> > > Please find our first version for the YANG model for IKEv2. Feel free >> to post comments. I would be also happy to have face-to-face >> discussions on the draft - especially from IKEv2 implementers. >> > > Might be good for me to have a talk about it, especially because I'm > not a yang person. . I'm still a bit confused about the syntax. There is > code in the document that looks like "ready to use" but also looks like > "example to use". like: > > description > "This YANG module defines the configuration and operational > state data for Internet Key Exchange version 2 (IKEv2) on > IETF draft. > Copyright (c) 2016 Ericsson AB. > All rights reserved."; > > All rights reserved? huh? Is that an example? or is this an error? > > I'm confused about units too, like: > > leaf initial-retransmission-timeout { > type uint32; > description > "initial retransmission timeout value"; > } > > look weird to me. What's the unit here? uint32 is not a unit, it is > a number Is this seconds? miliseconds? seconds since 1970? Since 1772? > > Some of it looks like just copying IANA registries? So that would be > outdated quickly. How would that get updated? Should we really put > chunks of code in RFCs like that? > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b33dc50879e01052f21f8dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

I leave my co-a= uthors to respond on the YANG aspects.

Regarding the initial-= retransmission-timeout I think we meant a time in second. Do you think we n= eed more options?

BR,
Daniel

On Mon, Mar 28, 2016 at 11:29 A= M, Paul Wouters <paul@nohats.ca> wrote:
On Sun, 27 Mar 2016, Daniel Migault wrote:

Subject: [IPsec] FW: New Version Notification for
=C2=A0 =C2=A0 draft-tran-ipsecme-ikev2-yang-00.txt

Please find our first version for the YANG model for IKEv2. Feel free
to post comments. I would be also happy to have face-to-face
discussions on the draft - especially from IKEv2 implementers.

 Might be good for me to have a talk about it, especially because I'm not a yang person. . I'm still a bit confused about the syntax. There i= s
code in the document that looks like "ready to use" but also look= s like
"example to use". like:

=C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0"This YANG module defines the configuration= and operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 state data for Internet Key Exchange version 2 = (IKEv2) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Copyright (c) 2016 Ericsson AB.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 All rights reserved.";

All rights reserved? huh? Is that an example? or is this an error?

I'm confused about units too, like:

=C2=A0 leaf initial-retransmission-timeout {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"initial retransmissio= n timeout value";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

look weird to me. What's the unit here? uint32 is not a unit, it is
a number Is this seconds? miliseconds? seconds since 1970? Since 1772?

Some of it looks like just copying IANA registries? So that would be
outdated quickly. How would that get updated? Should we really put
chunks of code in RFCs like that?

Paul


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

--047d7b33dc50879e01052f21f8dd-- From nobody Mon Mar 28 15:06:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EAA12D4FD for ; Mon, 28 Mar 2016 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=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 NqXZ2JZGIDtS for ; Mon, 28 Mar 2016 15:06:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7205512D13F for ; Mon, 28 Mar 2016 15:06:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qYnzW4br7z3C5; Tue, 29 Mar 2016 00:05:59 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fUQ17qpPirsK; Tue, 29 Mar 2016 00:05:58 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 29 Mar 2016 00:05:57 +0200 (CEST) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 3840A600B97E; Mon, 28 Mar 2016 18:05:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3840A600B97E References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-19BB6E14-C1C7-46A2-8ACA-BC073ABE19F5 Content-Transfer-Encoding: 7bit Message-Id: <8205E6F5-3B3F-4DF9-BA3A-AE5C5DF6F1A4@nohats.ca> X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Mon, 28 Mar 2016 18:05:45 -0400 To: Daniel Migault Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 22:06:03 -0000 --Apple-Mail-19BB6E14-C1C7-46A2-8ACA-BC073ABE19F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Mar 28, 2016, at 16:43, Daniel Migault wr= ote: >=20 > Hi Paul,=20 >=20 > I leave my co-authors to respond on the YANG aspects.=20 >=20 > Regarding the initial-retransmission-timeout I think we meant a time in se= cond. Do you think we need more options? Libreswan retransmits at 0.5 second and the doubling the interval up to 30 s= econds. So 0.5, 1, 2, 4, 8, 16. I don't think that you can put that in? Note I didn't read all the options, there might be others too. I think to be= sure, you need to look at various implementations and see if it can work. Paul > BR,=20 > Daniel >=20 >> On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters wrote: >> On Sun, 27 Mar 2016, Daniel Migault wrote: >>=20 >>> Subject: [IPsec] FW: New Version Notification for >>> draft-tran-ipsecme-ikev2-yang-00.txt >>=20 >>> Please find our first version for the YANG model for IKEv2. Feel free >>> to post comments. I would be also happy to have face-to-face >>> discussions on the draft - especially from IKEv2 implementers. >>=20 >> Might be good for me to have a talk about it, especially because I'm >> not a yang person. . I'm still a bit confused about the syntax. There is >> code in the document that looks like "ready to use" but also looks like >> "example to use". like: >>=20 >> description >> "This YANG module defines the configuration and operational >> state data for Internet Key Exchange version 2 (IKEv2) on >> IETF draft. >> Copyright (c) 2016 Ericsson AB. >> All rights reserved."; >>=20 >> All rights reserved? huh? Is that an example? or is this an error? >>=20 >> I'm confused about units too, like: >>=20 >> leaf initial-retransmission-timeout { >> type uint32; >> description >> "initial retransmission timeout value"; >> } >>=20 >> look weird to me. What's the unit here? uint32 is not a unit, it is >> a number Is this seconds? miliseconds? seconds since 1970? Since 1772? >>=20 >> Some of it looks like just copying IANA registries? So that would be >> outdated quickly. How would that get updated? Should we really put >> chunks of code in RFCs like that? >>=20 >> Paul >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-19BB6E14-C1C7-46A2-8ACA-BC073ABE19F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Mar 28, 2016, at 16:43, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Paul= ,

I leave my co-authors to respond on the YANG aspects.
Regarding the initial-retransmission-timeout I think we meant a time= in second. Do you think we need more options?

Libreswan retransmits at 0.5 second and the doubli= ng the interval up to 30 seconds. So 0.5, 1, 2, 4, 8, 16.

I don't think that you can put that in?

Note I did= n't read all the options, there might be others too. I think to be sure, you= need to look at various implementations and see if it can work.
<= div>
Paul

BR,
Daniel

=
On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters <paul= @nohats.ca> wrote:
On Sun, 27 M= ar 2016, Daniel Migault wrote:

Subject: [IPsec] FW: New Version Notification for
    draft-tran-ipsecme-ikev2-yang-00.txt

Please find our first version for the YANG model for IKEv2. Feel free
to post comments. I would be also happy to have face-to-face
discussions on the draft - especially from IKEv2 implementers.

 Might be good for me to have a talk about it, especially because I'm
not a yang person. . I'm still a bit confused about the syntax. There is
= code in the document that looks like "ready to use" but also looks like
"example to use". like:

  description
       "This YANG module defines the configuration and o= perational
        state data for Internet Key Exchange version 2 (= IKEv2) on
        IETF draft.
        Copyright (c) 2016 Ericsson AB.
        All rights reserved.";

All rights reserved? huh? Is that an example? or is this an error?

I'm confused about units too, like:

  leaf initial-retransmission-timeout {
           type uint32;
           description
             "initial retransmission time= out value";
         }

look weird to me. What's the unit here? uint32 is not a unit, it is
a number Is this seconds? miliseconds? seconds since 1970? Since 1772?

Some of it looks like just copying IANA registries? So that would be
outdated quickly. How would that get updated? Should we really put
chunks of code in RFCs like that?

Paul


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

____________________= ___________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai= lman/listinfo/ipsec
= --Apple-Mail-19BB6E14-C1C7-46A2-8ACA-BC073ABE19F5-- From nobody Mon Mar 28 16:31:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7494D12D160 for ; Mon, 28 Mar 2016 16:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 29t0qnWSQijv for ; Mon, 28 Mar 2016 16:31:50 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817FB12D0CF for ; Mon, 28 Mar 2016 16:31:49 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 20so2513604wmh.1 for ; Mon, 28 Mar 2016 16:31:49 -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:date:message-id:subject :from:to:cc; bh=S2SPgvNUeTGec0lPRYPR6dtjZnlOzf7415Negl1gt14=; b=FKQi+F+9WxN3LH5poZ4i6i7DTJ0LRr6N0Jb/qUsJkQ3W9LR20L90PtiK7kKK7t9e1S 2PKhk1xgeZ6nE/YFu9Qt8rip4ySRc21tzIpIXsxbdDxTAUEjLoVPQ6H8thQUr1pzpogh EExkCeu4Fv2CbPjvuGWqHl+MdtwcQ8TfJVhN5ky8lhAGycwZz8tqKGpnpo7qyKwbdkAe IZJCgBkFs3GYuZO+0Ib8ushO4FTJHPiYYJ8kSr6srfUjUMRu41ZRiIH1vmPmF+UJ8NsO qERi4o+MXZB1tuyJ2XqBiPvgx/latkwQsMvYXGjd+rFJwspwRyp8GLDdGEeR8c7dePUK oLyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S2SPgvNUeTGec0lPRYPR6dtjZnlOzf7415Negl1gt14=; b=RMACZal33vLlVLkzCAQhcHrjUHurypzkABVHqMOyGpW7G69ts5cNzB/7MYmWKxDliU S4HZ8Qlk1vIMvkic7OPK7jj21TNBy3yToeAIr8FGR4pJB33L99Eer8DUEaQeyIdbAyUD iKYoIOt879Ys0ZUJLySjWTAl/bwD5rGtPgF1BFNmhgrvnU9LSHQGmWlMHFsHu0wuDOcQ wDIYhg3iHp7PuX/6A8ZNr+bFs8zL1uM+cxWenvhrm+demhBjpAxWhznQOLEq9k/wUZ79 if13JGfZcPkq6o5j11dMs076hQkMG2OZfgrqadeDE3exj3idAejSeUmVS9mSoWwgL6HB vrDQ== X-Gm-Message-State: AD7BkJIXcuhpWmPSd1jCoZBR5BgF7RGcOQwgQDIV9gmgsLHTydkHu2DotjSpXN+48M/NPvtdYHlIi5MpAyXa3A== MIME-Version: 1.0 X-Received: by 10.194.184.234 with SMTP id ex10mr29224602wjc.8.1459207908077; Mon, 28 Mar 2016 16:31:48 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.171 with HTTP; Mon, 28 Mar 2016 16:31:47 -0700 (PDT) Received: by 10.194.78.171 with HTTP; Mon, 28 Mar 2016 16:31:47 -0700 (PDT) In-Reply-To: <8205E6F5-3B3F-4DF9-BA3A-AE5C5DF6F1A4@nohats.ca> References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> <8205E6F5-3B3F-4DF9-BA3A-AE5C5DF6F1A4@nohats.ca> Date: Mon, 28 Mar 2016 20:31:47 -0300 X-Google-Sender-Auth: 6c4KnWWOK59RHWNabt_MlMSUjd8 Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7b86cc1e03bb21052f2451a4 Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:31:52 -0000 --047d7b86cc1e03bb21052f2451a4 Content-Type: text/plain; charset=UTF-8 With the second as a unit. We cannot do it. However if we set it millisecond we are fine. We also have a field that specify the policy. This field should provide the policies of the different implementtation. Such feed back is definitely usefull for the next iteration of the draft. BR Daniel On Mar 28, 2016 18:06, "Paul Wouters" wrote: > > > Sent from my iPhone > > On Mar 28, 2016, at 16:43, Daniel Migault > wrote: > > Hi Paul, > > I leave my co-authors to respond on the YANG aspects. > > Regarding the initial-retransmission-timeout I think we meant a time in > second. Do you think we need more options? > > > Libreswan retransmits at 0.5 second and the doubling the interval up to 30 > seconds. So 0.5, 1, 2, 4, 8, 16. > > I don't think that you can put that in? > > Note I didn't read all the options, there might be others too. I think to > be sure, you need to look at various implementations and see if it can work. > > Paul > > BR, > Daniel > > On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters wrote: > >> On Sun, 27 Mar 2016, Daniel Migault wrote: >> >> Subject: [IPsec] FW: New Version Notification for >>> draft-tran-ipsecme-ikev2-yang-00.txt >>> >> >> Please find our first version for the YANG model for IKEv2. Feel free >>> to post comments. I would be also happy to have face-to-face >>> discussions on the draft - especially from IKEv2 implementers. >>> >> >> Might be good for me to have a talk about it, especially because I'm >> not a yang person. . I'm still a bit confused about the syntax. There is >> code in the document that looks like "ready to use" but also looks like >> "example to use". like: >> >> description >> "This YANG module defines the configuration and operational >> state data for Internet Key Exchange version 2 (IKEv2) on >> IETF draft. >> Copyright (c) 2016 Ericsson AB. >> All rights reserved."; >> >> All rights reserved? huh? Is that an example? or is this an error? >> >> I'm confused about units too, like: >> >> leaf initial-retransmission-timeout { >> type uint32; >> description >> "initial retransmission timeout value"; >> } >> >> look weird to me. What's the unit here? uint32 is not a unit, it is >> a number Is this seconds? miliseconds? seconds since 1970? Since 1772? >> >> Some of it looks like just copying IANA registries? So that would be >> outdated quickly. How would that get updated? Should we really put >> chunks of code in RFCs like that? >> >> 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 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --047d7b86cc1e03bb21052f2451a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

With the second as a unit. We cannot do it. However if we se= t it millisecond we are fine. We also have a field that specify the policy.= This field should provide the policies of the different implementtation.= =C2=A0 Such feed back is definitely usefull for the next iteration of the d= raft.

BR
Daniel

On Mar 28, 2016 18:06, "Paul Wouters" = <paul@nohats.ca> wrote:

=
Sent from my iPhone

On Mar 28, 2016, at 16:43, Daniel Mig= ault <d= aniel.migault@ericsson.com> wrote:

Hi Paul,

I le= ave my co-authors to respond on the YANG aspects.

Regarding t= he initial-retransmission-timeout I think we meant a time in second. Do you= think we need more options?
<= br>
Libreswan retransmits at 0.5 second and the doubling the interval = up to 30 seconds. So 0.5, 1, 2, 4, 8, 16.

I don't th= ink that you can put that in?

Note I didn't re= ad all the options, there might be others too. I think to be sure, you need= to look at various implementations and see if it can work.
=
Paul

BR,
Daniel

=
On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters <= span dir=3D"ltr"><pa= ul@nohats.ca> wrote:
On Sun= , 27 Mar 2016, Daniel Migault wrote:

Subject: [IPsec] FW: New Version Notification for
=C2=A0 =C2=A0 draft-tran-ipsecme-ikev2-yang-00.txt

Please find our first version for the YANG model for IKEv2. Feel free
to post comments. I would be also happy to have face-to-face
discussions on the draft - especially from IKEv2 implementers.

 Might be good for me to have a talk about it, especially because I'm not a yang person. . I'm still a bit confused about the syntax. There i= s
code in the document that looks like "ready to use" but also look= s like
"example to use". like:

=C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0"This YANG module defines the configuration= and operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 state data for Internet Key Exchange version 2 = (IKEv2) on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Copyright (c) 2016 Ericsson AB.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 All rights reserved.";

All rights reserved? huh? Is that an example? or is this an error?

I'm confused about units too, like:

=C2=A0 leaf initial-retransmission-timeout {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"initial retransmissio= n timeout value";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

look weird to me. What's the unit here? uint32 is not a unit, it is
a number Is this seconds? miliseconds? seconds since 1970? Since 1772?

Some of it looks like just copying IANA registries? So that would be
outdated quickly. How would that get updated? Should we really put
chunks of code in RFCs like that?

Paul


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

___________________= ____________________________
IPsec mailing list
<= span>IPsec@ietf.org=
https://www.ietf.org/mailman/listinfo/ipsec
<= /div>

___________________________________= ____________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--047d7b86cc1e03bb21052f2451a4-- From nobody Mon Mar 28 16:36:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F0512D104 for ; Mon, 28 Mar 2016 16:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 vBWlfpyG9_g1 for ; Mon, 28 Mar 2016 16:36:01 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A61712D0CF for ; Mon, 28 Mar 2016 16:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1459208161; x=2323121761; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IN7U0NMoQn+oLAJ7/1yKivHUHZvrFbdiQ/yZw04T2Gc=; b=0GL3fNZZICoCJGqOG2SenYt7ucqazd5fDqV+DCoOlzwWG0xccpJQ60hhwgMmn5Dj H0A3O5iOBabHp9G5gYlIwJe0AvATdSUhZ8gszsNOpas/6YBBz59VEZQ62yV4s9a9 O0CXoOMS7TgMnv7rO2VcQc6fsJmUM2PKem5DEk8uaHOc8vLpnUjJFIZO+kg8JCdK VAzkKxnE0zyUHOuiTLF8ieqHbfVE31xdVgl767jcYOYPKV1JJwNxRBPzjOgk/dDd gKeCWBwcRduBgrwnvEk2JwlX5aMy+Wq4m3pe26ojcbBVwVmI3bkXW+4HyxcF6cTd sVTK3Mw+bDLcaeC4MJgumQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 31.F4.21445.1EFB9F65; Mon, 28 Mar 2016 16:36:01 -0700 (PDT) X-AuditID: 11973e12-f79796d0000053c5-1f-56f9bfe136db Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 56.51.25582.0EFB9F65; Mon, 28 Mar 2016 16:36:01 -0700 (PDT) Received: from [17.153.41.232] by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O4R00C56W7ZR140@sesame.apple.com> for ipsec@ietf.org; Mon, 28 Mar 2016 16:36:00 -0700 (PDT) Sender: tpauly@apple.com MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) Content-type: multipart/alternative; boundary="Apple-Mail=_5C8CBD76-3492-4116-9333-6965AE4AE5B2" From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Mon, 28 Mar 2016 16:35:59 -0700 Message-id: <2425B76D-34DB-49C9-86C1-98C4A2031C3B@apple.com> References: To: Valery Smyslov X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUi2FAYoftw/88wgzub+Sz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ+v9zMWrF3NUvG3cxdzA+OGh8xdjJwcEgImEnsvbWWEsMUk LtxbzwZiCwnsZZTY8tsfpubDvCdMXYxcQPGZTBK7l6xghHC+MEqs+/4KaBIHh7CAhMTmPYkg DcICjhJ7Wu8xgYR5BfQlfp0JBzGZBZIkXj2IBalgE1CROP5tA9QJvBIz2p+ygNicAuYSjd++ MoHYLAKqEnP2TgWzmQWEJBYugDiTV8BGovn4H1aIMzMl/l5eBdYrAlR/c9tPqJmyEneOn2YB uVJC4AibxIbul4wTGEVmIVw0C+GiWWAbtCWWLXzNDGFrSuzvXs6CKa4h0fltIusCRrZVjEK5 iZk5upl5JnqJBQU5qXrJ+bmbGEExMt1OaAfjqVVWhxgFOBiVeHgjFv0ME2JNLCuuzD3EKM3B oiTOW7P0R5iQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRs+WrTKrFr809Iv+5K29pJvz1mW/ urh7wR0TLMNnTP5SE/BM+YRN2Qt53cs5PUs4vI3uH//zX2LFftMv6RG3D2flnjzkO+vBjpNR jds3bqzLWt77/M5NS1+h3Z4/smVX/LtR/Ek14jvzvpn3Fx2N068U/Pj6xZnH++49u3VxUXXm mfUTX19x/sKmxFKckWioxVxUnAgAJjDTjnICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUi2FDcoPtw/88wg5tT2C32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ+v9zMWrF3NUvG3cxdzA+OGh8xdjJwcEgImEh/mPWGCsMUk Ltxbz9bFyMUhJDCTSWL3khWMEM4XRol1318BdXBwCAtISGzekwjSICzgKLGn9R4TSJhXQF/i 15lwEJNZIEni1YNYkAo2ARWJ4982QK3ilZjR/pQFxOYUMJdo/PYVbC2LgKrEnL1TwWxmASGJ hQu2MoLYvAI2Es3H/7CC2EICmRJ/L68C6xUBqr+57SfUTFmJO8dPs0xgFJyFcMQshCNmgQ3V lli28DUzhK0psb97OQumuIZE57eJrAsY2VYxChSl5iRWmuolFhTkpOol5+duYgQHdWHEDsb/ y6wOMQpwMCrx8EYs+hkmxJpYVlyZe4hRgoNZSYTXbB9QiDclsbIqtSg/vqg0J7X4EONERqAf JzJLiSbnA2MuryTe0MTEwMTY2MzY2NzEnJbCSuK8rdKvw4QE0hNLUrNTUwtSi2COYuLglGpg NNQRY5izY5qV8HFDHx0B19Xnrj+a7i+45GOJ3oLp7//0NGi05rbYhiTMObD33bcSlQvXmtNq Qv6+zWQWXMg54brKVudjwjfjF95++ElGOCdwzuGruuq6qz+KlT41jK9/9O3gkQkHXxlW//v+ a46dOjO3gF3ux93MiUrxuXNzGCMrFjN3sS6dpMRSnJFoqMVcVJwIAGUmwMjdAgAA Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:36:04 -0000 --Apple-Mail=_5C8CBD76-3492-4116-9333-6965AE4AE5B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, Thanks for reviewing the draft. I appreciate your time looking at it! Regarding the status of mentioning TLS in the draft, I think it is = important for the standardization aspect of running IKEv2/IPSec over a = stream. While much of the reason to run IPSec over TCP/TLS is to work on = networks that currently do not pass UDP traffic, there is broader = benefit in describing how the IKEv2 protocol should work over a = streaming protocol, and when a layer like TLS is used. The main points I = want to make sure we retain in the spec are: - If you use a streaming protocol like TCP to transport your IKEv2/IPSec = traffic, use the framing described in the document to define the = boundaries of IKE and ESP messages - TCP segments and TLS frames (if used) should not affect the creation = or parsing of IKEv2/IPSec messages - Extra layers that use a security protocol, like TLS, should not be = considered to provide any security or authentication assurances at the = IKE level. Since we expect deployments for the short to use TLS, I want to make = sure we are clear on these details so that deployments do the right = thing. I do believe there is a need for the basic elements of this in a = standards document. I do like the idea of having a follow-on draft that is not Standards = Track that describes current best practices for how to use TLS and TCP = encapsulation to solve current problems. Note that the current draft = does not specify what port to use, etc, and only mentions that = implementations may end up choosing to use port 443. This follow-on = draft can go into detail about exactly what algorithms deployments end = up choosing (try first over UDP with N packets, then try over TLS port = 443, etc).=20 Responses to specific points inline. Thanks, Tommy > On Mar 23, 2016, at 5:03 AM, Valery Smyslov wrote: >=20 > Hi Tommy, > =20 > I reviewed the draft.=20 > =20 > Generally, the draft is in a good shape. It is well written and = contains almost no > editorial issues. There are however some places where I'd like to see = more > clarification, all of them are listed below. > =20 > My main problem with the draft is that it has an intended status = Standards Track and=20 > at the same time its main goal, as specified in the Introduction, is = to invent > some hack to cheat middleboxes that don't pass UDP. In this context > the proposal to use TLS (and port 443) looks especially ugly, however = it is probably > the most "penetrating" solution. I understand that the world is not = perfect and=20 > we must deal with it. However I think that the Standards Track = documents must try > to model more or less ideal world (to some extent) and should not = standardize hacks,=20 > tricks and so on. > =20 > On the other hand, TCP encapsulation per se doesn't look bad, and I = think it is worth=20 > to have standard interoperable solution to encapsulate IKE and ESP in = TCP.=20 > I would have had much less problems with this proposal it the draft = was splitted=20 > into two documents - one Standards Track document describing TCP = encapsulation > per se, and the other Informational document describing all the hacks = and tricks=20 > to cheat the middleboxes that try not to pass anything except e.g. = http and/or https. > And I'd like all the TLS encapsulation stuff go into that draft. > =20 > =20 > =20 > 1. The requirement that direct use of ESP or UDP Encapsulation SHOULD = be preferred over using TCP > Encapsulation is present twice in the document (in Sections 1 and = 2). I think it's OK to reemphasize=20 > this requirement, however since both of them use RFC2119 language, = they look duplicated.=20 > I'd suggest to change one of the SHOULDs to lower case. Good point, will change one of the SHOULDs to lower case in the next = version. > =20 > 2. Section 3. > =20 > Although a TCP stream may be able to send very long messages, > implementations SHOULD limit message lengths to typical UDP = datagram > ESP payload lengths. The maximum message length is used as the > effective MTU for connections that are being encrypted using ESP, = so > the maximum message length will influence characteristics of inner > connections, such as the TCP Maximum Segment Size (MSS). > this text is not clear for me. IKE and ESP message length can be = up > to 64Kbytes, so how it can be used as effective MTU (that is less = than or > equal to the interface MTU, that is usually about 1500 bytes)? > How it can influence MSS, that is usually less than or equal to=20 > path MTU to avoid IP fragmentation? Am I missing something? The point I=E2=80=99m trying to get at is this: if the IPSec tunnel is = represented to the client system as a virtual interface, that virtual = interface will have an MTU which determines the packet size of packets = within the tunnel. Depending on how IPSec over TCP is implemented on the = server end, the ESP packets could eventually be sent over UDP before = being decrypted (specifically, if the TCP connection is terminated at a = device before the IKE endpoint). As such, we want to make sure that = there are not very large (such as 64K bytes) IKE and ESP messages being = sent on a tunnel that may have to then fragmenting the ESP datagrams = before decrypting them. > =20 > 3. Section 4. > =20 > Any specific IKE SA, along with its Child SAs, is either TCP > encapsulated or not. A mix of TCP and UDP encapsulation for a = single > SA is not allowed. The exception to this rule is SAs that are > migrated between addresses using MOBIKE Section 7. > =20 > the last sentence is not accurate. As far as I understand, if IKE = SA (along with=20 > its Child SAs) migrated from one address to another via MOBIKE, = then=20 > either all these SAs (IKE & its children) use TCP encapsulation > or all them use traditional encapsulation. So, it is not an = exception > from the rule. Well, my reading of the rule that "the mix is not = allowed" > is that by "mix" you mean situation when IKE SA uses one type > of encapsulation while some of its children use different type. > I'd suggest to clarify this text so that any ambiguity is = eliminated. You are correct that there is not a case in which there is a mix between = IKE and Child SAs. We will clarify this in the next version. > =20 > 4. Section 5. > =20 > A peer must discard a partially received message due to a broken > connection. > =20 > s/must/MUST ? I think we can make this a MUST. > =20 > 5. Section 9. > =20 > NAT keep-alive packets over a TCP > encapsulated IPSec connection will be sent with a length value of 1 > byte, whose value is 0xFF Figure 2. > =20 > Shouldn't "Figure 2" be enclosed in brackets? Agreed, this can be in brackets. > =20 > 6. Section 11. > =20 > There is no subsection describing additional overhead to the size = of the ESP=20 > and IKE messages when using TCP encapsulation. > This overhead may be important for some implementations. Consider = some > application (e.g. VoIP) that sends small packets, e.g. about 50 = bytes in size. > With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = =3D 36 bytes. > With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 = (IP) =3D 52 bytes. > The difference may be significant for low bandwith networks or low = power consumption > devices. With TLS the situation will be worse. This calculation does not work exactly, since TCP is a stream and the = IKE/ESP payloads will not correspond directly with TLS frames or TCP = segments. We can mention the overhead in general, but it is not a = deterministic factor. > =20 > 7. Section 11.3 > =20 > It is not clear from the text where NULL cipher should be used - = in ESP > or in TLS? If it is about TLS, then does by NULL cipher you mean > TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS=20 > (I'm not a TLS expert)? If it is about ESP NULL cipher,=20 > then it contradicts to last para in Section 12... I think it = should be clarified. This should refer to the TLS NULL cipher, not ESP. > =20 > 8. The draft is silent about ESP Sequence Numbers. I think a few words = could=20 > be added that while the ESP SN are unnecessary with TCP = encapsulation, > the sender still must increnet it in every sent packet. Okay, we can add a comment for that. > =20 > Regards, > Valery Smyslov. > =20 > =20 > =20 > =20 >> ----- Original Message -----=20 >> From: Tommy Pauly >> To: ipsec@ietf.org >> Sent: Tuesday, February 16, 2016 12:52 AM >> Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft >>=20 >> Hello all, >>=20 >> I=E2=80=99ve just posted a new version of the IKEv2 and IPSec TCP = Encapsulation draft. The changes include: >>=20 >> - Making the use case (as a last resort if UDP is blocked) more clear = in the introduction >> - Clarify connection establishment and teardown section (allowing a = resumed connection to start with either IKE or ESP traffic, allowing = multiple SAs on one TCP connection) >> - Adding more details about interactions with IKEv2 fragmentation, = and TCP MSS and QoS markings >> - Clarifying the keep-alive/DPD section >> - A new appendix written by a new author from Cisco giving four = example exchanges with TCP encapsulation of IKEv2. >>=20 >> https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt = >> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 = >>=20 >> I believe this should address many of the comments the last draft = received. Please take a look and provide your feedback! If the working = group is in favor, I=E2=80=99d like to see if this can be adopted by the = working group. >>=20 >> Thanks, >> Tommy >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 = --Apple-Mail=_5C8CBD76-3492-4116-9333-6965AE4AE5B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Valery,

Thanks for reviewing the draft. I = appreciate your time looking at it!

Regarding the status of mentioning TLS = in the draft, I think it is important for the standardization aspect of = running IKEv2/IPSec over a stream. While much of the reason to run IPSec = over TCP/TLS is to work on networks that currently do not pass UDP = traffic, there is broader benefit in describing how the IKEv2 protocol = should work over a streaming protocol, and when a layer like TLS is = used. The main points I want to make sure we retain in the spec = are:
- If you use a streaming protocol like TCP to = transport your IKEv2/IPSec traffic, use the framing described in the = document to define the boundaries of IKE and ESP messages
- TCP segments and TLS frames (if used) should not affect the = creation or parsing of IKEv2/IPSec messages
- Extra = layers that use a security protocol, like TLS, should not be considered = to provide any security or authentication assurances at the IKE = level.

Since = we expect deployments for the short to use TLS, I want to make sure we = are clear on these details so that deployments do the right thing. I do = believe there is a need for the basic elements of this in a standards = document.

I do = like the idea of having a follow-on draft that is not Standards Track = that describes current best practices for how to use TLS and TCP = encapsulation to solve current problems. Note that the current draft = does not specify what port to use, etc, and only mentions that = implementations may end up choosing to use port 443. This follow-on = draft can go into detail about exactly what algorithms deployments end = up choosing (try first over UDP with N packets, then try over TLS port = 443, etc). 

Responses to specific points inline.

Thanks,
Tommy

On Mar 23, 2016, at 5:03 AM, Valery Smyslov = <svanru@gmail.com> wrote:

Hi Tommy,
 
I reviewed the draft. 
 
Generally, the draft is in a good = shape. It is well written and contains almost no
editorial issues. There are = however some places where I'd like to see more
clarification, all of them are = listed below.
 
My main problem with the draft is that it has an intended = status Standards Track and 
at the same time its main goal, = as specified in the Introduction, is to invent
some hack to cheat middleboxes = that don't pass UDP. In this context
the proposal to use TLS (and port = 443) looks especially ugly, however it is probably
the most "penetrating" solution. = I understand that the world is not perfect and 
we must deal with it. However I = think that the Standards Track documents must try
to model more or less ideal world = (to some extent) and should not standardize hacks, 
tricks and so = on.
 
On the other hand, TCP encapsulation per se doesn't look bad, = and I think it is worth 
to have standard interoperable solution to encapsulate IKE and ESP in = TCP. 
I would have had much less = problems with this proposal it the draft was splitted 
into two documents - one = Standards Track document describing TCP encapsulation
per se, and the other = Informational document describing all the hacks and tricks 
to cheat the middleboxes that try = not to pass anything except e.g. http and/or https.
And I'd like all the TLS = encapsulation stuff go into that draft.
 
 
 
1. The requirement that direct = use of ESP or UDP Encapsulation SHOULD be preferred over using = TCP
    Encapsulation is present twice in the = document (in Sections 1 and 2). I think it's OK to reemphasize 
    this = requirement, however since both of them use RFC2119 language, they = look duplicated. 
    I'd suggest to = change one of the SHOULDs to lower = case.

Good = point, will change one of the SHOULDs to lower case in the next = version.

 
2. Section 3.
 
   Although a TCP stream may be able to send = very long messages,
   implementations SHOULD = limit message lengths to typical UDP datagram
   = ESP payload lengths.  The maximum message length is used as the
   effective MTU for connections that are being = encrypted using ESP, so
   the maximum message = length will influence characteristics of inner
   = connections, such as the TCP Maximum Segment Size (MSS).
    this text is not clear for me. IKE and = ESP message length can be up
    to 64Kbytes, so how it can be used as = effective MTU (that is less than or
    equal to the = interface MTU, that is usually about 1500 bytes)?
    How it can = influence MSS, that is usually less than or equal to 
    path MTU to = avoid IP fragmentation? Am I missing = something?

The point I=E2=80=99m trying to get at is this: if = the IPSec tunnel is represented to the client system as a virtual = interface, that virtual interface will have an MTU which determines the = packet size of packets within the tunnel. Depending on how IPSec over = TCP is implemented on the server end, the ESP packets could eventually = be sent over UDP before being decrypted (specifically, if the TCP = connection is terminated at a device before the IKE endpoint). As such, = we want to make sure that there are not very large (such as 64K bytes) = IKE and ESP messages being sent on a tunnel that may have to then = fragmenting the ESP datagrams before decrypting them.

 
3. Section 4.
 
   Any specific IKE SA, = along with its Child SAs, is either TCP
   = encapsulated or not.  A mix of TCP and UDP encapsulation for a = single
   SA is not allowed.  The exception = to this rule is SAs that are
   migrated between = addresses using MOBIKE Section 7.
 
    the last sentence is not = accurate. As far as I understand, if IKE SA (along with 
    its Child = SAs) migrated from one address = to another via MOBIKE, then 
    either all = these SAs (IKE & its children) use TCP = encapsulation
    or all them use traditional encapsulation. = So, it is not an exception
    from the rule. Well, my reading of the = rule that "the mix is not allowed"
    is that by = "mix" you mean situation when IKE SA uses one type
    of = encapsulation while some of its children use different = type.
    I'd suggest to clarify this text so that = any ambiguity is eliminated.

You are correct that there is not a case in which = there is a mix between IKE and Child SAs. We will clarify this in the = next version.

    
4. Section 5.
 
   A peer must discard = a partially received message due to a broken
   = connection.
 
    s/must/MUST = ?

I think we = can make this a MUST.

 
5. Section 9.
 
    NAT keep-alive packets over a TCP
   encapsulated IPSec connection will be sent with = a length value of 1
   byte, whose value is 0xFF = Figure 2.
 
    Shouldn't "Figure 2" be enclosed in = brackets?

Agreed, this can be in brackets.

 
6. Section 11.
 
    There is no = subsection describing additional overhead to the size of the = ESP 
    and IKE = messages when using TCP encapsulation.
    This overhead = may be important for some implementations. Consider = some
    application (e.g. VoIP) that sends small = packets, e.g. about 50 bytes in size.
    With UDP = encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = =3D 36 bytes.
    With TCP encapsulation it is 8 (ESP) = + 4 (len) + 20 (TCP) + 20 (IP) =3D 52 bytes.
    The difference = may be significant for low bandwith networks or low power = consumption
    devices. With TLS the situation will be = worse.

This = calculation does not work exactly, since TCP is a stream and the IKE/ESP = payloads will not correspond directly with TLS frames or TCP segments. = We can mention the overhead in general, but it is not a deterministic = factor.

 
7. Section 11.3
    
    It is not = clear from the text where NULL cipher should be used - in = ESP
    or in TLS? If it is about TLS, then does = by NULL cipher you mean
    TLS_NULL_WITH_NULL_NULL or something else? = Is it MTI in TLS 
    (I'm not a TLS = expert)? If it is = about ESP NULL cipher, 
    then it = contradicts to last para in Section 12... I think it = should be clarified.

This should refer to the TLS NULL cipher, not = ESP.

 
8. The draft is silent about ESP Sequence Numbers. I think a = few words could 
    be added that = while the ESP SN are unnecessary with TCP = encapsulation,
    the sender still must increnet it in = every sent packet.

Okay, we can add a comment for that.

 
Regards,
Valery Smyslov.
    
 
 
 
----- Original Message ----- 
From: Tommy Pauly
To: ipsec@ietf.org
Sent: Tuesday, February 16, 2016 = 12:52 AM
Subject: [IPsec] New version of = IKEv2 TCP Encapsulation draft

Hello all,

I=E2=80=99ve just posted a new version of the IKEv2 and IPSec = TCP Encapsulation draft. The changes include:

- Making the use case (as a last resort = if UDP is blocked) more clear in the introduction
- = Clarify connection establishment and teardown section (allowing a = resumed connection to start with either IKE or ESP traffic, allowing = multiple SAs on one TCP connection)
- Adding more = details about interactions with IKEv2 fragmentation, and TCP MSS and QoS = markings
- Clarifying the keep-alive/DPD = section
- A new appendix written by a new author = from Cisco giving four example exchanges with TCP encapsulation of = IKEv2.

https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt=
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03

I believe = this should address many of the comments the last draft received. Please = take a look and provide your feedback! If the working group is in favor, = I=E2=80=99d like to see if this can be adopted by the working = group.

Thanks,
Tommy



_________________________________= ______________
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

= --Apple-Mail=_5C8CBD76-3492-4116-9333-6965AE4AE5B2-- From nobody Mon Mar 28 16:37:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122F112D0E5 for ; Mon, 28 Mar 2016 16:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com 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 zjVY_q8BfiyH for ; Mon, 28 Mar 2016 16:37:11 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B85612D0CF for ; Mon, 28 Mar 2016 16:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1459208231; x=2323121831; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CwhZ5O+u8zuB0bX3PZ2YSULcSHNbnsyFi5Re14rbXgY=; b=dGYSbG6glRgsq9uQwC9qMxclCudRHyKQ8jNr8P1YG47/w0AQbijGW3TlY7//62S+ bGLKq8fixvdj43hTXh09WCaAL6q5lOHSoo0n8TqpUxEOjRIsgGQrJmxzJueEhia/ qaTUe7e423g/cc0HpMwiYz7Bc4Dt0L62+zFlaQnQIEjHwM1PDAROR8BNKipcqAas Zzg8a+HhtUk16iyMFIzVJVYBqCSjTIZZHj9OwUHRPAHjCXH7/+3A1viCNaOaAF4r HVbItnUazBBB1NMfr0CXirsSXsELrBzMu3k5igTeTC7fw9/HCcDhsQ1+XMG+76UD Co2ZEThBQKeFtbv+IDJeeg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 51.48.03030.720C9F65; Mon, 28 Mar 2016 16:37:11 -0700 (PDT) X-AuditID: 11973e13-f798e6d000000bd6-38-56f9c0270a57 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 2B.F2.25582.620C9F65; Mon, 28 Mar 2016 16:37:11 -0700 (PDT) Received: from [17.153.41.232] by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O4R00C71W9XR140@sesame.apple.com> for ipsec@ietf.org; Mon, 28 Mar 2016 16:37:10 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_5FBE798D-A97A-48AD-98B6-0F3F15E57CDB" MIME-version: 1.0 (Mac OS X Mail 10.0 \(3167\)) From: Tommy Pauly In-reply-to: Date: Mon, 28 Mar 2016 16:37:09 -0700 Message-id: <43ECE08C-EECE-44BC-9105-D042C1038958@apple.com> References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> <8205E6F5-3B3F-4DF9-BA3A-AE5C5DF6F1A4@nohats.ca> To: Daniel Migault X-Mailer: Apple Mail (2.3167) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAYoat+4GeYweOTHBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoz5y9gKTsdWLL6zjr2BsSOgi5GTQ0LARKJrxjcmCFtM4sK9 9WxdjFwcQgJ7GSU2vF7I2sXIAVY0718ORHwmk8TvGSfZIZwvjBLPvj9kBykSFpCQ2LwnEWQQ s0CSxJGu32C9vAL6Er/OhIOEhQUiJI4evAC2i01AReL4tw3MICWcAsESN1tsQcIsAqoSH5Ye Z4WY4i6x4v0jRhCbV8BG4sbdKWBxIYEDzBJvH+mA2CICBhIvJ+xkgzhfVuLO8dMsIJdJCOxh kzgw7THzBEbhWUgumoVwEURYW2LZwtfMIGFmAR2JyQsZUYUh7I/njzAtYGRbxSiUm5iZo5uZ Z6qXWFCQk6qXnJ+7iREUB9PthHcwnl5ldYhRgINRiYc3YtHPMCHWxLLiytxDjNIcLErivNVL f4QJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGz+6JjuYT9ZmX/a5OazZt8mMG0s2Ses/vMS //7V2zaeeH1g9qWyrFnFLcHzNhtWHvqxtFJ9S/3Te/9vPNgr6MxcuMKrp321uoxKquXhlPhF qd4np+/5e/u3ktjWJYbP9x56r96QcPB7uIvigqwrZbz/7XZX+vRw+rM5ndjI8vuJW2+t4gre mCAlluKMREMt5qLiRAAkcqceZAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUi2FDcoKt+4GeYwcYVjBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoz5y9gKTsdWLL6zjr2BsSOgi5GDQ0LARGLev5wuRk4gU0zi wr31bF2MXBxCAjOZJH7POMkO4XxhlHj2/SE7SIOwgITE5j2JIA3MAkkSR7p+s4KEeQX0JX6d CQcJCwtESBw9eIEJxGYTUJE4/m0DM0gJp0CwxM0WW5Awi4CqxIelx1khprhLrHj/iBHE5hWw kbhxdwpYXEjgALPE20c6ILaIgIHEywk72SDOlJW4c/w0ywRGgVlIjpiFcAREWFti2cLXzCBh ZgEdickLGVGFIeyP548wLWBkW8UoUJSak1hpqpdYUJCTqpecn7uJERy2hRE7GP8vszrEKMDB qMTDG7HoZ5gQa2JZcWXuIUYJDmYlEV6zfUAh3pTEyqrUovz4otKc1OJDjBMZgX6cyCwlmpwP jKq8knhDExMDE2NjM2NjcxNzWgorifO2Sr8OExJITyxJzU5NLUgtgjmKiYNTqoFRq3WXHFf+ 75uTba+yswje7WfUOHozdX1lTPiO9Ek1k52LD5WZfZn14KGy45b7P0wZLzGdDEw66rJozpEX 1ed/a24KfVGze27gArtCdo7jvb7T7m/2bZHufbn15M6idWuE47V/CW9+NHPhytPqMs07T1x1 f1cpO19tyTXuOHfHPU7/pr2eE1XxRomlOCPRUIu5qDgRAF0omoHOAgAA Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:37:13 -0000 --Apple-Mail=_5FBE798D-A97A-48AD-98B6-0F3F15E57CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree that time intervals for IKE retransmits should be measured in = milliseconds, not seconds. Thanks, Tommy > On Mar 28, 2016, at 4:31 PM, Daniel Migault = wrote: >=20 > With the second as a unit. We cannot do it. However if we set it = millisecond we are fine. We also have a field that specify the policy. = This field should provide the policies of the different implementtation. = Such feed back is definitely usefull for the next iteration of the = draft. >=20 > BR > Daniel >=20 > On Mar 28, 2016 18:06, "Paul Wouters" > wrote: >=20 >=20 > Sent from my iPhone >=20 > On Mar 28, 2016, at 16:43, Daniel Migault > wrote: >=20 >> Hi Paul,=20 >>=20 >> I leave my co-authors to respond on the YANG aspects.=20 >>=20 >> Regarding the initial-retransmission-timeout I think we meant a time = in second. Do you think we need more options? >=20 > Libreswan retransmits at 0.5 second and the doubling the interval up = to 30 seconds. So 0.5, 1, 2, 4, 8, 16. >=20 > I don't think that you can put that in? >=20 > Note I didn't read all the options, there might be others too. I think = to be sure, you need to look at various implementations and see if it = can work. >=20 > Paul >=20 >> BR,=20 >> Daniel >>=20 >> On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters > wrote: >> On Sun, 27 Mar 2016, Daniel Migault wrote: >>=20 >> Subject: [IPsec] FW: New Version Notification for >> draft-tran-ipsecme-ikev2-yang-00.txt >>=20 >> Please find our first version for the YANG model for IKEv2. Feel free >> to post comments. I would be also happy to have face-to-face >> discussions on the draft - especially from IKEv2 implementers. >>=20 >> Might be good for me to have a talk about it, especially because I'm >> not a yang person. . I'm still a bit confused about the syntax. There = is >> code in the document that looks like "ready to use" but also looks = like >> "example to use". like: >>=20 >> description >> "This YANG module defines the configuration and operational >> state data for Internet Key Exchange version 2 (IKEv2) on >> IETF draft. >> Copyright (c) 2016 Ericsson AB. >> All rights reserved."; >>=20 >> All rights reserved? huh? Is that an example? or is this an error? >>=20 >> I'm confused about units too, like: >>=20 >> leaf initial-retransmission-timeout { >> type uint32; >> description >> "initial retransmission timeout value"; >> } >>=20 >> look weird to me. What's the unit here? uint32 is not a unit, it is >> a number Is this seconds? miliseconds? seconds since 1970? Since = 1772? >>=20 >> Some of it looks like just copying IANA registries? So that would be >> outdated quickly. How would that get updated? Should we really put >> chunks of code in RFCs like that? >>=20 >> Paul >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_5FBE798D-A97A-48AD-98B6-0F3F15E57CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I agree that time intervals for IKE = retransmits should be measured in milliseconds, not seconds.

Thanks,
Tommy

On Mar 28, 2016, at 4:31 PM, Daniel Migault = <daniel.migault@ericsson.com> wrote:

With the second as a unit. We cannot do it. However if we set = it millisecond we are fine. We also have a field that specify the = policy. This field should provide the policies of the different = implementtation.  Such feed back is definitely usefull for the next = iteration of the draft.

BR
Daniel

On Mar 28, 2016 18:06, "Paul Wouters" <paul@nohats.ca> = wrote:


Sent from my iPhone

On Mar 28, 2016, at 16:43, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Paul,

I = leave my co-authors to respond on the YANG aspects.

Regarding the initial-retransmission-timeout I think we = meant a time in second. Do you think we need more options?

Libreswan retransmits at 0.5 second and the doubling = the interval up to 30 seconds. So 0.5, 1, 2, 4, 8, 16.

I don't think that you can put that = in?

Note I = didn't read all the options, there might be others too. I think to be = sure, you need to look at various implementations and see if it can = work.

Paul

BR,
Daniel

On Mon, = Mar 28, 2016 at 11:29 AM, Paul Wouters <paul@nohats.ca> wrote:
On Sun, 27 Mar 2016, Daniel Migault wrote:

Subject: [IPsec] FW: New Version Notification for
    draft-tran-ipsecme-ikev2-yang-00.txt

Please find our first version for the YANG model for IKEv2. Feel free
to post comments. I would be also happy to have face-to-face
discussions on the draft - especially from IKEv2 implementers.

 Might be good for me to have a talk about it, especially because I'm
not a yang person. . I'm still a bit confused about the syntax. There = is
code in the document that looks like "ready to use" but also looks = like
"example to use". like:

  description
       "This YANG module defines the configuration = and operational
        state data for Internet Key Exchange version = 2 (IKEv2) on
        IETF draft.
        Copyright (c) 2016 Ericsson AB.
=         All rights reserved.";

All rights reserved? huh? Is that an example? or is this an error?

I'm confused about units too, like:

  leaf initial-retransmission-timeout {
           type uint32;
           description
             "initial retransmission = timeout value";
         }

look weird to me. What's the unit here? uint32 is not a unit, it is
a number Is this seconds? miliseconds? seconds since 1970? Since = 1772?

Some of it looks like just copying IANA registries? So that would be
outdated quickly. How would that get updated? Should we really put
chunks of code in RFCs like that?

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

_______________________________________________
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

= --Apple-Mail=_5FBE798D-A97A-48AD-98B6-0F3F15E57CDB-- From nobody Mon Mar 28 16:39:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C08312D0CF for ; Mon, 28 Mar 2016 16:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IoWkkdKgxiH3 for ; Mon, 28 Mar 2016 16:39:42 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B375412D104 for ; Mon, 28 Mar 2016 16:39:41 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id 139so565945wmn.2 for ; Mon, 28 Mar 2016 16:39:41 -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:date:message-id:subject :from:to:cc; bh=/edWNGmXc4utT8NP4TFWqAQh0K3MkTZDbDkCht2SgG0=; b=luYVH/tqfDWEe6G+QLjwWZdjIQpqpzV4VpI1u68W52sf0a9de2trNmW50vs17x7vvL Q4zHPncX+VWl5YLGOy4o4zw74QXx6meIyQsA2qFxHYVumXstTpBRCPQirJEh6G+hu8LR pDPRbWj5gWT0IYJuKjdYe07veUJuFCJihUaN++jnpmPK+xlnfY7+xEcTu1jq59/2kZKs lJCJwNvT9uzKyvtgGKJmgC7MgljF6k4AOAjnc10r9HNStRCE1UC+yMJ7qc1lFjLdCEDP h2epVTQlevqmrVI9tWHeaez/tEecqFNjCccRCwDCUt/dB0udGIbf4kPpBbYc8UDEFJHP 5RQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/edWNGmXc4utT8NP4TFWqAQh0K3MkTZDbDkCht2SgG0=; b=U6Vf+PeC15PRCNvu+ox5YcLX0DLBmpzQYnJ2tQInAiBS2UAnxYD4+Lsf/asaytEGbJ WTtbvrPlmWMxD0vzc/iY1MKNiyO3toaX2Y+nsNDR6+buGgP9+2M+VdlfR54dU1aRYfTo jwSBgwuY91hPP2kcVuqJq9etFpCuoqaGtox85PyC2hPlnCDgNZjNNUfrP4lDQyEd908h 83uFAcynIS23AMAFXVp32i5w2QXesW9dVM8Yvzdc6dUVuk1VRxb7Tqy5zF/8I2+E0+Vq 0qS/5+6T1z7rnXTb1mUusPGA+IcpTmXbmHfdxduBGoQfnpgDlp2DaxaUukEhqeBI//x4 ZzEQ== X-Gm-Message-State: AD7BkJKAMUF6Vq6xONHnXWow8t+fhKEUOVMgXSXIZdKmJOleeiEWNShzStgBRFmEjcIQgUPPz/WO9v+1lf7LRg== MIME-Version: 1.0 X-Received: by 10.28.145.196 with SMTP id t187mr12524477wmd.81.1459208379900; Mon, 28 Mar 2016 16:39:39 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.171 with HTTP; Mon, 28 Mar 2016 16:39:39 -0700 (PDT) Received: by 10.194.78.171 with HTTP; Mon, 28 Mar 2016 16:39:39 -0700 (PDT) In-Reply-To: References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> Date: Mon, 28 Mar 2016 20:39:39 -0300 X-Google-Sender-Auth: 1z8Boa_Aq-1OdS8D2UGzZECZ2uw Message-ID: From: Daniel Migault To: Gabriel Lopez Content-Type: multipart/alternative; boundary=001a11469348232921052f246de0 Archived-At: Cc: "Nagendran Ramalingam \(Nagendran.Ramalingam@huawei.com\)" , Xufeng Liu , IPsecME WG , "Wanghonglei \(A\) \(stonewater.wang@huawei.com\)" , "Chenxia \(D\) \(jescia.chenxia@huawei.com\)" , "Wunan \(Eric\) \(eric.wu@huawei.com\)" , Khanh Tran , Ing-Wher Chen , "Lizhenbin \(lizhenbin@huawei.com\)" , "vijay kn \(vijay.kn@huawei.com\)" Subject: Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:39:44 -0000 --001a11469348232921052f246de0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gabriel, Thanks for the feed back. For IKEv2 the document to consider is draft-tran-ipsecme-ikev2-yang-00. I agree that it would be usefull to have some basic example. This is in our plane. However i am wondering if the basic scenaos should rather concern ipsec confirurations than ikev2. Please let us know what are the scenario you would like us to document. BR Daniel Hi, Documents draft-tran-ipsecme-yang-01 and draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date (2016-03-18) and most of the authors coincide. Both documents describe a Yang IKEv2 configuration data model. The latter is focused on IKEv2, the former includes IPSec and IKEv1 data models. Sorry, I=E2=80=99m a bit confused, what is the right document to check the = IKEv2 yang model? In both cases, it would be useful to include examples for basic IPSec/IKE scenarios. Regards, Gabi. El 27 mar 2016, a las 1:04, Daniel Migault escribi=C3=B3: Hi, Please find our first version for the YANG model for IKEv2. Feel free to post comments. I would be also happy to have face-to-face discussions on the draft - especially from IKEv2 implementers. BR, Daniel -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ] Sent: Friday, March 18, 2016 11:01 AM To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj; Daniel Migault Subject: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt has been successfully submitted by Khanh Tran and posted to the IETF repository. Name: draft-tran-ipsecme-ikev2-yang Revision: 00 Title: Yang Data Model for IKEv2 Document date: 2016-03-18 Group: Individual Submission Pages: 76 URL: https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/ Htmlized: https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-0= 0 Abstract: This document defines a YANG data model that can be used to configure and manage Internet Key Exchange version 2 (IKEv2). The model covers the IKEv2 protocol configuration and operational state. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --001a11469348232921052f246de0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Gabriel,
Thanks for the feed back.

For IKEv2 the document to consider is=C2=A0 draft-tran-ipsec= me-ikev2-yang-00.

I agree that it would be usefull to have some basic example.= This is in our plane.
However i am wondering if the basic scenaos should rather concern ipsec con= firurations than ikev2.
Please let us know what are the scenario you would like us to document.

BR
Daniel


Hi,

Documents draft-tra= n-ipsecme-yang-01 and draft-tran-ipsecme-ikev2-yang-00 have been submitted = the same date (2016-03-18) and most of the authors coincide. Both documents= describe a Yang IKEv2 configuration data model. The latter is focused on I= KEv2, the former includes IPSec and IKEv1 data models.

=
Sorry, I=E2=80=99m a bit confused, what is the right document to check= the IKEv2 yang model?

In both cases, it would be = useful to include examples for basic IPSec/IKE scenarios.

Regards, Gabi.


El 27 mar 2016, a las 1:04, Daniel Migault <daniel.migault@ericsson.com> escribi=C3=B3:

Hi,

Please find our first v= ersion for the YANG model for IKEv2. Feel free to post comments. I would be= also happy to have face-to-face discussions on the draft - especially from= IKEv2 implementers.

BR,
Daniel =C2=A0

-----Original Mess= age-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Friday= , March 18, 2016 11:01 AM
To: Xia Chen; Honglei Wang; Khanh Tran; Khanh = Tran; Vijay Kumar Nagaraj; Daniel Migault
Subject: New Version Notificat= ion for draft-tran-ipsecme-ikev2-yang-00.txt


A new version of I-= D, draft-tran-ipsecme-ikev2-yang-00.txt
has been successfully submitted = by Khanh Tran and posted to the IETF repository.

Name: draft-tran-ipsecme-ikev2-yang
Revision: 00
Title: Yang Data Model for IKEv2
Docume= nt date: 2016-03-18
Group: Individual Submission
Pages: 76
URL: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ik= ev2-yang-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0https://datatracker.ietf.org/doc/draft-tran-ipsecm= e-ikev2-yang/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00

Abstract:
=C2=A0=C2=A0This document defines a YANG data model= that can be used to
=C2=A0=C2=A0configure and manage Internet Key Exch= ange version 2 (IKEv2).=C2=A0 The
=C2=A0=C2=A0model covers the IKEv2 pr= otocol configuration and operational state.






Plea= se note that it may take a couple of minutes from the time of submission un= til the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat=

_______________________________________________
IPsec mailing li= st
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



------------------= -----------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n=
Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaci= ones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34= 868884151
email:=C2=A0gabilm@um.es





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

--001a11469348232921052f246de0-- From nobody Tue Mar 29 03:38:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60B12D658 for ; Tue, 29 Mar 2016 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 i8uiI-ZNHD9N for ; Tue, 29 Mar 2016 03:38:17 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5240012D656 for ; Tue, 29 Mar 2016 03:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 5DAD3354C; Tue, 29 Mar 2016 12:30:13 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cCMZ+FeVKZ2H; Tue, 29 Mar 2016 12:30:13 +0200 (CEST) Received: from [192.168.1.3] (106.Red-81-36-109.dynamicIP.rima-tde.net [81.36.109.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon24.um.es (Postfix) with ESMTPSA id 4B96E587; Tue, 29 Mar 2016 12:30:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8575B213-0D88-467A-B464-F0E58B4D0F25"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Gabriel Lopez In-Reply-To: Date: Tue, 29 Mar 2016 12:30:03 +0200 Message-Id: <2A869DA3-B068-4B95-A214-6B2B263898EA@um.es> References: <20160318180059.2743.10884.idtracker@ietfa.amsl.com> <2D1BA3CFD799FD44A1F3650A84C4000F1231AFBC@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C11222B1D5@eusaamb108.ericsson.se> To: Daniel Migault X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Nagendran Ramalingam \(Nagendran.Ramalingam@huawei.com\)" , Xufeng Liu , IPsecME WG , "Wanghonglei \(A\) \(stonewater.wang@huawei.com\)" , "Chenxia \(D\) \(jescia.chenxia@huawei.com\)" , "Wunan \(Eric\) \(eric.wu@huawei.com\)" , Khanh Tran , Ing-Wher Chen , "Lizhenbin \(lizhenbin@huawei.com\)" , "vijay kn \(vijay.kn@huawei.com\)" Subject: Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 10:38:21 -0000 --Apple-Mail=_8575B213-0D88-467A-B464-F0E58B4D0F25 Content-Type: multipart/alternative; boundary="Apple-Mail=_A370AB4E-EB8F-49A9-BCCC-040B1765CEEA" --Apple-Mail=_A370AB4E-EB8F-49A9-BCCC-040B1765CEEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Daniel, > El 29 mar 2016, a las 1:39, Daniel Migault = escribi=C3=B3: >=20 > Hi Gabriel, > Thanks for the feed back. >=20 > For IKEv2 the document to consider is = draft-tran-ipsecme-ikev2-yang-00. >=20 >=20 ok, then I suggest the authors to remove the IKEv2 model from = draft-tran-ipsecme-yang-01 >=20 > I agree that it would be usefull to have some basic example. This is = in our plane. > However i am wondering if the basic scenaos should rather concern = ipsec confirurations than ikev2. > Please let us know what are the scenario you would like us to = document. >=20 >=20 Let=E2=80=99s suppose a very basic, manually defined, end-to-end ipsec = configuration for ipsec-tools. #SAD info (1) add 192.168.56.1 192.168.56.2 ah 0x200 -A hmac-md5 0x12345=E2=80=A6. (2) add 192.168.56.2. 192.168.56.1 ah 0x300 -A hmac-md5 0x98765=E2=80=A6. #SPD info (3) spdadd 192.168.56.1 192.168.56.2 any -P out ipsec = ah/transport//require; (4) spdadd 192.168.56.2 192.168.56.1 any -P in ipsec = ah/transport//require; =46rom draft-tran-ipsecme-yang-01, let=E2=80=99s try to model the first = sentence (1): ipsec/sad/sad-entries/ ipsec/sad/sad-entries/spi=3D0x200 ipsec/sad/sad-entries/anti-replay-window=3D ipsec/sad/sad-entries/ip-comp=3D ipsec/sad/sad-entries/local-peer=3D192.168.56.1 ipsec/sad/sad-entries/local-remote=3D192.168.56.2 ipsec/sad/sad-entries/sa-mode=3Dtransport ipsec/sad/sad-entries/security-protocol=3Dah ipsec/sad/sad-entries/sequence-number=3D ipsec/sad/sad-entries/sequence-number-overflow-flag=3D ipsec/sad/sad-entries/path-mtu=3D ipsec/sad/sad-entries/life-time=3D ipsec/sad/sad-entries/upper-protocol=3D <=E2=80=94=E2=80=94Why = upper-protocol in the SAD entry? ipsec/sad/sad-entries/direction=3D <=E2=80=94 =C2=BF? ipsec/sad/sad-entries/source-address=3D <=E2=80=94 For tunnel = mode? ipsec/sad/sad-entries/destination-address=3D <=E2=80=94 " ipsec/sad/sad-entries/nat-traversal-flag=3D = ipsec/sad/sad-entries/ah/authentication-algorithm=3Dhmac-md5-96/0x12345=E2= =80=A6.. <=E2=80=94Why key-str is defined like 16/40 string/hex? for the second sentence (2): ipsec/sad/sad-entries/spi=3D0x300 ipsec/sad/sad-entries/local-peer=3D192.168.56.2 ipsec/sad/sad-entries/local-remote=3D192.168.56.1 ipsec/sad/sad-entries/sa-mode=3Dtransport ipsec/sad/sad-entries/security-protocol=3Dah = ipsec/sad/sad-entries/ah/authentication-algorithm=3Dhmac-md5-96/0x98765=E2= =80=A6.. =E2=80=A6 (omitted) .. for the third sentence (3): ipsec/spd/spd-entries/ ipsec/spd/spd-entries/name=3Dfoo ipsec/spd/spd-entries/description=3Dfoo desc ipsec/spd/spd-entries/anti-replay-windows=3D <=E2=80=94 already used = in sad, RFC4301 allocates this value in the SAD entry ipsec/spd/spd-entries/perfect-forward-secrecy=3D ipsec/spd/spd-entries/seq ipsec/spd/spd-entries/seq/seq-id <=E2=80=94 =C2=BF?= can be define more than one proposal per spd entry? ipsec/spd/spd-entries/seq/proposal =E2=80=94> /ipsec/proposal/ ipsec/spd/spd-entries/seq/proposal =E2=80=94> /ipsec/proposal/name=3Dfoo ipsec/spd/spd-entries/seq/proposal =E2=80=94> = /ipsec/proposal/ah=3Dauth-hmac-md5-96 <=E2=80=94Why do you make use = here of the type ike-integrity-algorithm-t using a different name than = in the sad entry? ipsec/spd/spd-entries/seq/proposal =E2=80=94> /ipsec/proposal/esp=3D ipsec/spd/spd-entries/seq/proposal =E2=80=94> /ipsec/proposal/ip-comp=3D = <=E2=80=94 already used in sad? ipsec/spd/spd-entries/seq/proposal =E2=80=94> /ipsec/proposal/lifetime=3D However, the spd entry model does not contain values such as local and = remote IP address (as described in RFC4301), ipsec mode = (transport/tunnel), direction, Next Layer Protocol, PFP flags, etc. Best regards, Gabi. > BR > Daniel >=20 >=20 > Hi, >=20 > Documents draft-tran-ipsecme-yang-01 and = draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date = (2016-03-18) and most of the authors coincide. Both documents describe a = Yang IKEv2 configuration data model. The latter is focused on IKEv2, the = former includes IPSec and IKEv1 data models. >=20 > Sorry, I=E2=80=99m a bit confused, what is the right document to check = the IKEv2 yang model? >=20 > In both cases, it would be useful to include examples for basic = IPSec/IKE scenarios. >=20 > Regards, Gabi. >=20 >=20 >> El 27 mar 2016, a las 1:04, Daniel Migault = > = escribi=C3=B3: >>=20 >> Hi, >>=20 >> Please find our first version for the YANG model for IKEv2. Feel free = to post comments. I would be also happy to have face-to-face discussions = on the draft - especially from IKEv2 implementers. >>=20 >> BR, >> Daniel >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org ] >> Sent: Friday, March 18, 2016 11:01 AM >> To: Xia Chen; Honglei Wang; Khanh Tran; Khanh Tran; Vijay Kumar = Nagaraj; Daniel Migault >> Subject: New Version Notification for = draft-tran-ipsecme-ikev2-yang-00.txt >>=20 >>=20 >> A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt >> has been successfully submitted by Khanh Tran and posted to the IETF = repository. >>=20 >> Name: draft-tran-ipsecme-ikev2-yang >> Revision: 00 >> Title: Yang Data Model for IKEv2 >> Document date: 2016-03-18 >> Group: Individual Submission >> Pages: 76 >> URL: = https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-yang-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/ = >> Htmlized: = https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00 = >>=20 >>=20 >> Abstract: >> This document defines a YANG data model that can be used to >> configure and manage Internet Key Exchange version 2 (IKEv2). The >> model covers the IKEv2 protocol configuration and operational = state. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 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 . >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 >=20 > ----------------------------------------------------------- > Gabriel L=C3=B3pez Mill=C3=A1n > Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email: gabilm@um.es >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_A370AB4E-EB8F-49A9-BCCC-040B1765CEEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Daniel,

El = 29 mar 2016, a las 1:39, Daniel Migault <daniel.migault@ericsson.com> escribi=C3=B3:

Hi Gabriel,
Thanks for the feed back.

For IKEv2 the = document to consider is  draft-tran-ipsecme-ikev2-yang-00.


ok, then I suggest = the authors to remove the IKEv2 model from = draft-tran-ipsecme-yang-01

I agree that it would be usefull to = have some basic example. This is in our plane.
However i am wondering if the basic scenaos should rather concern ipsec = confirurations than ikev2.
Please let us know what are the scenario you would like us to = document.



Let=E2=80= =99s suppose a very basic, manually defined, end-to-end ipsec = configuration for ipsec-tools.

#SAD = info
(1) add 192.168.56.1 192.168.56.2 ah 0x200 -A hmac-md5 = 0x12345=E2=80=A6.
(2) add 192.168.56.2. 192.168.56.1 ah 0x300 = -A hmac-md5 0x98765=E2=80=A6.

#SPD = info
(3) spdadd 192.168.56.1 192.168.56.2 any -P out ipsec = ah/transport//require;
(4) spdadd 192.168.56.2 192.168.56.1 = any -P in ipsec ah/transport//require;

=46rom draft-tran-ipsecme-yang-01, let=E2=80=99s = try to model the first sentence (1):

ipsec/sad/sad-entries/
ipsec/sad/sad-entri= es/spi=3D0x200
ipsec/sad/sad-entries/anti-replay-window=3D
=
ipsec/sad/sad-entries/ip-comp=3D
ipsec/sad/sad-entries/loca= l-peer=3D192.168.56.1
ipsec/sad/sad-entries/local-remote=3D= 192.168.56.2
ipsec/sad/sad-entries/sa-mode=3Dtransport 
ipsec/sad/sad-entries/security-protocol=3Dah
ipsec/sad/sad-entries/sequence-number=3D
ipsec/sad/sad-entries/sequence-number-overflow-flag=3D
ipsec/sad/sad-entries/path-mtu=3D
ipsec/sad/sad-entries/life-time=3D
ipsec/sad/sad-entries/upper-protocol=3D <=E2=80=94=E2=80= =94Why upper-protocol in the SAD entry?
ipsec/sad/sad-entries/direction=3D =  <=E2=80=94= =C2=BF?
ipsec/sad/sad-entries/source-address=3D <=E2=80=94 For tunnel = mode?
ipsec/sad/sad-entries/destination-address=3D <=E2=80=94 = "
ipsec/sad/sad-entries/nat-traversal-flag=3D
ipsec/sad/sad-entries/ah/authentication-algorithm=3Dhmac-md5-96= /0x12345=E2=80=A6.. <=E2=80=94Why key-str is defined like 16/40 = string/hex?

for = the second sentence (2):

ipsec/sad/sad-entries/spi=3D0x300
ipsec/sad/sad-= entries/local-peer=3D192.168.56.2
ipsec/sad/sad-entries/loc= al-remote=3D192.168.56.1
ipsec/sad/sad-entries/sa-mode=3Dtransport 
ipsec/sad/sad-entries/security-protocol=3Dah
ipsec/sad/sad-entries/ah/authentication-algorithm=3Dhmac-md5-96= /0x98765=E2=80=A6..
=E2=80=A6 (omitted) = ..

for = the third sentence (3):

ipsec/spd/spd-entries/
ipsec/spd/spd-entries/name=3Dfoo
ipsec/spd/spd-entries/description=3Dfoo desc
ipsec/spd/spd-entries/anti-replay-windows=3D  <=E2=80=94=  already used in sad, RFC4301 allocates this value in the SAD = entry
ipsec/spd/spd-entries/perfect-forward-secrecy=3D
ipsec/spd/spd-entries/seq
ipsec/spd/spd-entries/seq/seq-id  = <=E2=80=94 =C2=BF? can be define more than one proposal per = spd entry?
ipsec/spd/spd-entries/seq/proposal = =E2=80=94> /ipsec/proposal/
ipsec/spd/spd-entries/seq/proposal =E2=80=94> = /ipsec/proposal/name=3Dfoo
ipsec/spd/spd-entries/seq/proposal =E2=80=94> = /ipsec/proposal/ah=3Dauth-hmac-md5-96 <=E2=80=94Why do you make use here of = the type ike-integrity-algorithm-t using a different name than in the = sad entry?
ipsec/spd/spd-entries/seq/proposal = =E2=80=94> /ipsec/proposal/esp=3D
ipsec/spd/spd-entries/seq/proposal =E2=80=94> = /ipsec/proposal/ip-comp=3D   <=E2=80=94 already used in = sad?
ipsec/spd/spd-entries/seq/proposal =E2=80=94>= /ipsec/proposal/lifetime=3D  

However, the spd entry model does not = contain values such as local and remote IP address (as described in = RFC4301), ipsec mode (transport/tunnel), direction, Next Layer Protocol, = PFP flags, etc.



Best regards, Gabi.



BR
Daniel


Hi,

Documents draft-tran-ipsecme-yang-01 = and draft-tran-ipsecme-ikev2-yang-00 have been submitted the same date = (2016-03-18) and most of the authors coincide. Both documents describe a = Yang IKEv2 configuration data model. The latter is focused on IKEv2, the = former includes IPSec and IKEv1 data models.

Sorry, I=E2=80=99m a bit confused, what = is the right document to check the IKEv2 yang model?

In both cases, it would = be useful to include examples for basic IPSec/IKE scenarios.

Regards, Gabi.


El 27 mar 2016, a las 1:04, = Daniel Migault <daniel.migault@ericsson.com> = escribi=C3=B3:

Hi, =

Please find our first version for the YANG = model for IKEv2. Feel free to post comments. I would be also happy to = have face-to-face discussions on the draft - especially from IKEv2 = implementers.

BR,
Daniel =  

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Friday, March 18, 2016 11:01 AM
To: Xia Chen; Honglei = Wang; Khanh Tran; Khanh Tran; Vijay Kumar Nagaraj; Daniel Migault
Subject: New Version Notification for = draft-tran-ipsecme-ikev2-yang-00.txt


A new version of I-D, draft-tran-ipsecme-ikev2-yang-00.txt
has been successfully submitted by Khanh Tran and posted to = the IETF repository.

Name: = draft-tran-ipsecme-ikev2-yang
Revision: 00
Title: = Yang Data = Model for IKEv2
Document date: 2016-03-18
Group: = = Individual Submission
Pages: 76
URL: =            https://www.ietf.org/internet-drafts/draft-tran-ipsecme-ikev2-y= ang-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-tran-ipsecme-ikev2-yang/=
Htmlized:       https://tools.ietf.org/html/draft-tran-ipsecme-ikev2-yang-00


Abstract:
=   This document defines a YANG data model that can be used = to
  configure and manage Internet Key Exchange = version 2 (IKEv2).  The
  model covers the = IKEv2 protocol configuration and operational state.





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

The IETF = Secretariat

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es





_______________________________________________
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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_A370AB4E-EB8F-49A9-BCCC-040B1765CEEA-- --Apple-Mail=_8575B213-0D88-467A-B464-F0E58B4D0F25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW+lksAAoJEMUYqoSNEZFTqi8IAJB9N2qYYki29FYrH5IENk+s Ah4/f1fXwBEHXreW9GE6VoKy3A3QURFHGAvz42RJ4mkLdJrPmXKgK8YhrP5FXTNq /DAqDQENnBjncHpKZT7UEO+onF0aQxzQsm0yFruG4Qhun6TcqKCBzhzjM/cLp/hu i0ir/2/o+Szk0pwu/PdlUBmYTHn95nONbanJe3hYQRO9YWvFSNZGRgQZZPZP0smz +l3yh+qgboDiPoNkzMvb9yyVbP1PPttFAKC52l3Ka7zfcAELAlgbGfLyljtI3PXn E/TAlZd0Ez2L0YomsIzn3hxbAfzX9zu58yugBBKsbIYbpo7fb8o8molnr92WdFs= =LGkr -----END PGP SIGNATURE----- --Apple-Mail=_8575B213-0D88-467A-B464-F0E58B4D0F25-- From nobody Tue Mar 29 13:54:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7612D9C2 for ; Tue, 29 Mar 2016 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Wd8cTvh762Ah for ; Tue, 29 Mar 2016 13:54:37 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5574112DB93 for ; Tue, 29 Mar 2016 13:22:06 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-d1-56fae3c957b9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C4.17.22441.9C3EAF65; Tue, 29 Mar 2016 22:21:29 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 16:22:04 -0400 From: Khanh Tran To: "IPsec@ietf.org" Thread-Topic: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt Thread-Index: AdGJ91d9IonKpe9xR8Kp3mn7UJOXWg== Date: Tue, 29 Mar 2016 20:22:04 +0000 Message-ID: <2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPt+7Jx7/CDD69trHYv+UFmwOjx5Il P5kCGKO4bFJSczLLUov07RK4Ms6d+MpWsDm84vpNowbGWz5djJwcEgImEvu2L2eFsMUkLtxb z9bFyMUhJHCUUWJTxyd2CGc5o8S2vevAqtgEdCTOT1/GCGKLCKhKzO54ztzFyMEhLBAhMas1 GCIcK9G5axkThK0ncWn+XRYQmwWo/MLv9+wgNq+Ar0Tb0XVgcUagxd9PrQGrZxYQl7j1ZD4T xEECEkv2nGeGsEUlXj7+B3WoksSkpedYIerzJR6ea2eEmCkocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7S4ICc33chwEyMw7I9JsDnuYNzb63mI UYCDUYmHN2HlzzAh1sSy4srcQ4wSHMxKIrwFj36FCfGmJFZWpRblxxeV5qQWH2KU5mBREuf9 9vFymJBAemJJanZqakFqEUyWiYNTqoExMXT9zkuGt/UYqk4YhM69OuWYce7OVaJrNZXV1Dfc e+/xsciRQUrxS2xVyYuii3UPJ9r9Pmra9PK5y6bDXzQOumv37/kQnuu+pPv58sKUi7t3rfVS aYj+pTmpzt/O+3DFnwpGL1cvsxtbjXzEtvYIylgqnrocdvZxECN/iHjwrQPzdvI5HGlSYinO SDTUYi4qTgQAOcFDjHcCAAA= Archived-At: Subject: [IPsec] FW: New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:54:39 -0000 --_000_2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Below are my comments to your questions that are relating to draft-tran-ips= ecme-ikev2-yang-00.txt. Q1: What does all right reserved means? I think the question beyond that is= how the YANG model can be used, and who owns it? Can you respond to this? A1: Yes, we will remove the following description: " Copyright (c) 2016 Ericsson AB."+ " All rights reserved."; Q2: leaf initial-retransmission-timeout I think that the question is how = do we specify units in the YANG model. Is that something that is part of th= e YANG model? I think we should also ask if the WG would like us to add dif= ferent ways to express there transmission time out? - I can respond to this= question if you prefer. A2: yes, we can specify the unit for this attribute (I assume the unit will= be "miliseconds") Ex: leaf initial-retransmission-timeout { type uint32; units "miliseconds"; default 100; description "initial retransmission timeout value"; } leaf nat-keepalive-interval { type uint16 { range "5..300"; } units "Seconds"; default 20; description "NAT detected and keepalive interval"; } Q3: How YANG can be updated when IANA registries are updated. I think also = some text could be added into the draft for that. - Can you respond to this= ? A3: yes, we can add the text in the draft for reference to IANA. When IANA= registries are updated, the YANG module should be notified for changes and= update accordingly. Best regards, Khanh Tran --_000_2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

Below are my comments<= /span> to your questions that are relating to= draft-tran-ipsecme-ikev2-yang-00.txt.=

 

Q1: What does all right= reserved means? I think the question beyond that is how the YANG model can= be used, and who owns it? Can you respond to this?

A1: Yes, we will remov= e the following description:

   &nbs= p;   " Copyright (c) 20= 16 Ericsson AB."+

   &nbs= p;   " All rights reserved.";

 

 

Q2:   leaf initial-retransmission-timeout I think that the question is how do we= specify units in the YANG model. Is that something that is part of the YAN= G model? I think we should also ask if the WG would like us to add different ways to express there transmission time out= ? – I can respond to this question if you prefer.

A2: yes, we can specif= y the unit for this attribute (I assume the unit will be “miliseconds= ”)  

Ex:<= /p>

         leaf initial= -retransmission-timeout {

           = type uint32;

           units "miliseconds";

           default 100;

           = description

          &= nbsp;  "initial retransmission timeout value";

         }=

 

         leaf nat-kee= palive-interval {

          &= nbsp;  type uint16 {

          &= nbsp;    range "5..300";

          &= nbsp;  }

          &= nbsp;  units "Seconds";

          &= nbsp;  default 20;

          &= nbsp;  description "NAT detected and keepalive interval";

         }=

 

 

Q3: How YANG ca= n be updated when IANA registries are updated. I think also some text could= be added into the draft for that. – Can you respond to this?

A3: yes, we can add th= e text in the draft for reference to IANA.  When IANA registries are u= pdated, the YANG module should be notified for changes and update according= ly.

 

 

Best regards,

Khanh Tran<= /span>

--_000_2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0eusaamb107erics_--