From nobody Thu Nov 1 01:59:57 2018 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 3625E1286E7 for ; Thu, 1 Nov 2018 01:59:56 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.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 Paaw5yWT-rcF for ; Thu, 1 Nov 2018 01:59:54 -0700 (PDT) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 97E3712777C for ; Thu, 1 Nov 2018 01:59:54 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id c32so17089500otb.8 for ; Thu, 01 Nov 2018 01:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lf+dWMWo1Bxen9iYRFyPs2QznBdErwPzMXnV8JLvUiA=; b=Kmri0iRt3FByDUZpEf4Nh/HcJU4Njtd32bD0YrnhM4XyzgTIYdPtunn16o7DoTnerH w8+wm3iryVlT/ljBiprhMePh4EtaackUaZNkkFHLfiBzjE3VzFADQzpG3yRQaq8IWUoc cTouZkLw0clenWU3v+6ooPggwlDM8ku2FrUzewucc/NVFb4ML1xY01aj6ODmFpi/zcCd 3wJ++/Q3bfL+9E7oYbrOtd1+XqXm0NHvd+EYcM1zAOPD1u/PFXkRfRCUyewGGKfU1vSn qFk19b5G2YdFFqXu+9mRWnz1ulDbOwUaGzqFRYqPcWo9QTafyuFvjdTAOEijywKnlF/p anPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lf+dWMWo1Bxen9iYRFyPs2QznBdErwPzMXnV8JLvUiA=; b=fUj4ladHmVhCb1iVICw8hSURqEFhl3RrE5JHdbq9Umz6qKEEPsM0dJFTXZI8PGuEHi /DfxDzWjkC4rTVxdr+gcp7Ov5ZjUpzPEp20JJzACgd8qyYcCUEmsdlZBwBk11YaUburI ZJDibH3x6qM5TWTUIoN4igTeX6FL/RFNugbQeU1qh4uE5EBO/o5m0nefy+b52SqZM2IV uX0cNh8J1LPvYVr/P09I0e3vJ2wQdhXdIjqXptBGyCJcIWakndj8i+UjwPCx352kCNpH Ozbkl0T9o0hBKCUxDTBYQliB3pa8EUtocZCjsRNVMdAMykKvcNMOwl9hFVC9KRgw7rcG 5M7g== X-Gm-Message-State: AGRZ1gLN3X9liasE7hn0P41xRwcBS4qMPKeQMBcaTdasEAVcaNUvldmd jVon3lVf1hQtO+tREUYzin0JiEZkG+SNfrMGWjdQJA== X-Google-Smtp-Source: AJdET5eBnyJpydIPLwfJWCinmKf1LRzkcC2TaHuztnwQ0Lhz7aVbs7NlTRD5HBck0bXj/SZ28H16p7o7RUXLvqqaQJk= X-Received: by 2002:a9d:5293:: with SMTP id f19mr4309680oth.6.1541062793828; Thu, 01 Nov 2018 01:59:53 -0700 (PDT) MIME-Version: 1.0 References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> In-Reply-To: <23514.13527.860102.126373@fireball.acr.fi> From: CJ Tjhai Date: Thu, 1 Nov 2018 08:59:42 +0000 Message-ID: To: Tero Kivinen Cc: "Scott Fluhrer (sfluhrer)" , Valery Smyslov , ipsec@ietf.org, draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 08:59:56 -0000 Hi all, > > That implementation is broken, and needs to be fixed. What's the procedure on this? Is there a need to publish a document or some test vectors that all implementations can validate against? Personally, it is more logical to introduce new transform types for QSKEs, but one of my concerns is how can we guarantee that all broken implementations are fixed? Consider the following simplified proposal: SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | | 6 transforms) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) +-- Transform QSKE1 ( Name = Foobar ) +-- Transform QSKE2 ( Name = Zappa ) At the moment, some broken implementations may abort the exchange entirely and in some way, this helps as we may want to establish a connection with a broken implementation. On the other hand, there could be other implementations that ignore both QSKE1 and QSKE2 and return a response as if there is an implicit second proposal: | +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, | 4 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve25519 ) So more complex checks will be required to cater for all broken cases. I have no idea what response we will get from other broken implementations. Or alternatively, do we have to rely on another Notification payload to check for potential backward compatibility issues? I think it would be great to also get some thoughts from VPN manufacturers on this point. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. > > In section 3.3.6 this is explained very clearly: > > If the responder receives a proposal that contains a Transform Type > it does not understand, or a proposal that is missing a mandatory > Transform Type, it MUST consider this proposal unacceptable; however, > other proposals in the same SA payload are processed as usual. > Similarly, if the responder receives a transform that it does not > understand, or one that contains a Transform Attribute it does not > understand, it MUST consider this transform unacceptable; other > transforms with the same Transform Type are processed as usual. This > allows new Transform Types and Transform Attributes to be defined in > the future. > > I.e., the intention is that if there is transform type you do not > understand you skip whole proposal, but STILL PROCESS rest of the > proposals normally, i.e., this allows backward compatiblity. > Yes, this is how it should behave. Cheers, CJ From nobody Thu Nov 1 03:23:58 2018 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 4D6DA1294D0; Thu, 1 Nov 2018 03:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.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 YMUS5LlG4GLd; Thu, 1 Nov 2018 03:23:52 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10112.outbound.protection.outlook.com [40.107.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A081298C5; Thu, 1 Nov 2018 03:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philips.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pCmHtXRFuo6G7T1pPyhKUBeZcCrg5XRW/CO5wVwDEBM=; b=Xh0w2OzLFzC5Kt+HeG7aWmPWJ2SYiGT/nZF8HOhdQfPibnidydl1P33426w+5ZHRdxt/mb5ZKQvrblj82Ms65rhAzxpqfLzE2AyJjbhDJu2vyehlSVXrT+DRQlJC8nH9iGIEccae/irppQ6mG4q/FtOKMpcCtLv/UASZ5+ekOAg= Received: from VI1P122MB0109.EURP122.PROD.OUTLOOK.COM (20.176.11.20) by VI1P122MB0063.EURP122.PROD.OUTLOOK.COM (129.75.142.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.31; Thu, 1 Nov 2018 10:23:48 +0000 Received: from VI1P122MB0109.EURP122.PROD.OUTLOOK.COM ([fe80::bc44:3841:95ad:e430]) by VI1P122MB0109.EURP122.PROD.OUTLOOK.COM ([fe80::bc44:3841:95ad:e430%8]) with mapi id 15.20.1228.035; Thu, 1 Nov 2018 10:23:48 +0000 From: "Garcia-Morchon O, Oscar" To: CJ Tjhai , Tero Kivinen CC: "Scott Fluhrer (sfluhrer)" , Valery Smyslov , "ipsec@ietf.org" , "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 Thread-Index: AdRxISFkud4inQZOTYCMbnQCiNECBQABjTEgABGps4AAFM9RAAAFBKGA Date: Thu, 1 Nov 2018 10:23:47 +0000 Message-ID: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.garcia-morchon@philips.com; x-originating-ip: [194.171.252.112] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1P122MB0063; 6:+LM74MZhWOBqk5jiZSmj1l0mmDkK79n7yygZOQXkMY1ejPwYt0m7IjZfkQvl8F4eSBxE+Ywoht1k/tjlhtq5Abj4DFY0neHP9tMAc6+1slMdPQQ78SqCv7q2iFyk3di0crhiCvlF+IdZn10ZLihlbyHAO2GS/yfc/q0QOWxm+akOF6AytyZD409ngpCv13jxa+fB5KQhMukRIgoRKiFkGLdgJ1Xh24VVPPxj2N0ZzPEk7zZvgXZoEjemKDaXvtjBbKcB27bDws8krRzfzDAKdGQ1swdnyBjlz5KBgNRghht0aEJ58+1vA+BdWosRPxopOsb/UDWJFI9JaSK0M8QX/3r1gUxsTo1qN13VPwji85730W4KkavdLgRkovU8DGcJxefvTOdd3D2HIM/RsYb41ODEylcgtbrJDDntKnKm1tubyeWbLpsWiyLhaAsVdYc6iIct1pp1lbnzJKVxewKlSg==; 5:D7tmSZZqm7LsZsLv+x5mjKrHe9keHgbf5qJvOa37a76/TB1PUdY7kFVlbeN6rGX25rVIR2I/dqpTow9nD4qD9aTCG5CMPVdsa3KpfNL61sPd+R9vy7Gvlg+/bdeHiELV96/dh2/ZhWDIQajyaLP+y2CLcenkcooc95wjD8KuemQ=; 7:d5T+rNFSsxmgEHVieEWnlU12hZXjMa3cflgYnqX13RUGwieihfcAyk17q/E4Qi/7mwIXVNYEb3Cl8Q1P30GolVEKwnfCSVIo4wLUfbC5E87U/nbKr1tR+xJr3U9ZmBO+gK9rMEfwd+7FPwpZQnbX7wO+GeneGyg6u7fLminHRJiO/NCqu4BV2PXEed5jf7lowABujmtfsetfp7OuoXUinrJfhqCVkJ3eg/4VVcMCqh4a5SIAsmviwO7ag+LcM4i6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4230e8f5-bcae-42f1-033c-08d63fe41ca2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1P122MB0063; x-ms-traffictypediagnostic: VI1P122MB0063: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231382)(944501410)(52105095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1P122MB0063; BCL:0; PCL:0; RULEID:; SRVR:VI1P122MB0063; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(346002)(376002)(39860400002)(189003)(199004)(55904004)(374574003)(53754006)(71200400001)(6486002)(33656002)(97736004)(71190400001)(81166006)(6436002)(53936002)(476003)(26005)(186003)(106356001)(81156014)(105586002)(2906002)(6246003)(2616005)(14454004)(68736007)(305945005)(102836004)(82746002)(86362001)(7736002)(4326008)(83716004)(8676002)(25786009)(446003)(5250100002)(66066001)(39060400002)(561944003)(256004)(5660300001)(93886005)(11346002)(8936002)(6116002)(486006)(58126008)(3846002)(316002)(2900100001)(36756003)(110136005)(54906003)(76176011)(99286004)(6512007)(229853002)(478600001)(6506007)(14444005)(60764002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P122MB0063; H:VI1P122MB0109.EURP122.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: philips.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OGqUnLUtTEYzPFbzvxBMICFXZ4NKzJDx/saxojctNRK585BO7WBqQc26q3Tsu2MEXOnCcVdvjvLElFg/jqxakv5z7mrKFchvau5Xg/SZsH94rmuboWxluvdo2OZIDLuqFa7+hqn7FPtpgf4ptWr9nEg84qm4n9W+74VMQC+TIObZ/Uxtk4YmeEvbT5UYrIB7a9mnY9o5d9sza4ItfAnXXNmLrlNLhG7mIf/3tR3umEWih6Co0O06eawTkxJs1x4+sefBzVMPbIoQbS/eSAbiLKfVBS4v6SjaFp5bLftoBLGTwGbRN8Hjaf+kKRkLVLNt/pWG/I2TY9oFcCoIXSPO+GR1w+gi3crLYE+pltXvc/U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4230e8f5-bcae-42f1-033c-08d63fe41ca2 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 10:23:47.6920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P122MB0063 Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 10:23:57 -0000 DQoNCu+7v09uIDAxLzExLzIwMTgsIDEwOjAwLCAiQ0ogVGpoYWkiIDxjanRAcG9zdC1xdWFudHVt LmNvbT4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQoNCiAgICA+DQogICAgPiBUaGF0IGltcGxlbWVu dGF0aW9uIGlzIGJyb2tlbiwgYW5kIG5lZWRzIHRvIGJlIGZpeGVkLg0KDQogICAgV2hhdCdzIHRo ZSBwcm9jZWR1cmUgb24gdGhpcz8gSXMgdGhlcmUgYSBuZWVkIHRvIHB1Ymxpc2ggYSBkb2N1bWVu dCBvcg0KICAgIHNvbWUgdGVzdCB2ZWN0b3JzIHRoYXQgYWxsIGltcGxlbWVudGF0aW9ucyBjYW4g dmFsaWRhdGUgYWdhaW5zdD8NCg0KICAgIFBlcnNvbmFsbHksIGl0IGlzIG1vcmUgbG9naWNhbCB0 byBpbnRyb2R1Y2UgbmV3IHRyYW5zZm9ybSB0eXBlcyBmb3INCiAgICBRU0tFcywgYnV0IG9uZSBv ZiBteSBjb25jZXJucyBpcyBob3cgY2FuIHdlIGd1YXJhbnRlZSB0aGF0IGFsbCBicm9rZW4NCiAg ICBpbXBsZW1lbnRhdGlvbnMgYXJlIGZpeGVkPw0KDQo+PiBJIHdvdWxkIGFsc28gbm90IGtub3cg aG93IHRvIGd1YXJhbnRlZSB0aGF0IGFsbCBkZXBsb3llZCBicm9rZW4gaW1wbGVtZW50YXRpb25z IGNhbiBiZSBmaXhlZC4NCg0KICAgIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2ltcGxpZmllZCBw cm9wb3NhbDoNCg0KICAgIFNBIFBheWxvYWQNCiAgICAgICAgICB8DQogICAgICAgICAgKy0tLSBQ cm9wb3NhbCAjMSAoIFByb3RvIElEID0gSUtFKDEpLCBTUEkgc2l6ZSA9IDAsDQogICAgICAgICAg fCAgICAgIHwgICAgICAgICAgICA2IHRyYW5zZm9ybXMpDQogICAgICAgICAgICAgICAgKy0tIFRy YW5zZm9ybSBFTkNSICggTmFtZSA9IEVOQ1JfQUVTX0NCQyApDQogICAgICAgICAgICAgICAgfCAg ICAgKy0tIEF0dHJpYnV0ZSAoIEtleSBMZW5ndGggPSAyNTYgKQ0KICAgICAgICAgICAgICAgICst LSBUcmFuc2Zvcm0gUFJGICggTmFtZSA9IFBSRl9ITUFDX1NIQTJfNTEyICkNCiAgICAgICAgICAg ICAgICArLS0gVHJhbnNmb3JtIElOVEVHICggTmFtZSA9IEFVVEhfSE1BQ19TSEEyXzUxMl8yNTYg KQ0KICAgICAgICAgICAgICAgICstLSBUcmFuc2Zvcm0gRC1IICggTmFtZSA9IEN1cnZlMjU1MTkg KQ0KICAgICAgICAgICAgICAgICstLSBUcmFuc2Zvcm0gUVNLRTEgKCBOYW1lID0gRm9vYmFyICkN CiAgICAgICAgICAgICAgICArLS0gVHJhbnNmb3JtIFFTS0UyICggTmFtZSA9IFphcHBhICkNCg0K ICAgIEF0IHRoZSBtb21lbnQsIHNvbWUgYnJva2VuIGltcGxlbWVudGF0aW9ucyBtYXkgYWJvcnQg dGhlIGV4Y2hhbmdlDQogICAgZW50aXJlbHkgYW5kIGluIHNvbWUgd2F5LCB0aGlzIGhlbHBzIGFz IHdlIG1heSB3YW50IHRvIGVzdGFibGlzaCBhDQogICAgY29ubmVjdGlvbiB3aXRoIGEgYnJva2Vu IGltcGxlbWVudGF0aW9uLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUNCiAgICBjb3VsZCBiZSBv dGhlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBpZ25vcmUgYm90aCBRU0tFMSBhbmQgUVNLRTIgYW5k DQogICAgcmV0dXJuIGEgcmVzcG9uc2UgYXMgaWYgdGhlcmUgaXMgYW4gaW1wbGljaXQgc2Vjb25k IHByb3Bvc2FsOg0KICAgICAgICAgfA0KICAgICAgICAgICstLS0gUHJvcG9zYWwgIzIgKCBQcm90 byBJRCA9IElLRSgxKSwgU1BJIHNpemUgPSAwLA0KICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICA0IHRyYW5zZm9ybXMpDQogICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICstLSBU cmFuc2Zvcm0gRU5DUiAoIE5hbWUgPSBFTkNSX0FFU19DQkMgKQ0KICAgICAgICAgICAgICAgIHwg ICAgICstLSBBdHRyaWJ1dGUgKCBLZXkgTGVuZ3RoID0gMjU2ICkNCiAgICAgICAgICAgICAgICAr LS0gVHJhbnNmb3JtIFBSRiAoIE5hbWUgPSBQUkZfSE1BQ19TSEEyXzUxMiApDQogICAgICAgICAg ICAgICAgKy0tIFRyYW5zZm9ybSBJTlRFRyAoIE5hbWUgPSBBVVRIX0hNQUNfU0hBMl81MTJfMjU2 ICkNCiAgICAgICAgICAgICAgICArLS0gVHJhbnNmb3JtIEQtSCAoIE5hbWUgPSBDdXJ2ZTI1NTE5 ICkNCg0KICAgIFNvIG1vcmUgY29tcGxleCBjaGVja3Mgd2lsbCBiZSByZXF1aXJlZCB0byBjYXRl ciBmb3IgYWxsIGJyb2tlbiBjYXNlcy4NCiAgICBJIGhhdmUgbm8gaWRlYSB3aGF0IHJlc3BvbnNl IHdlIHdpbGwgZ2V0IGZyb20gb3RoZXIgYnJva2VuDQogICAgaW1wbGVtZW50YXRpb25zLg0KDQog ICAgT3IgYWx0ZXJuYXRpdmVseSwgZG8gd2UgaGF2ZSB0byByZWx5IG9uIGFub3RoZXIgTm90aWZp Y2F0aW9uIHBheWxvYWQNCiAgICB0byBjaGVjayBmb3IgcG90ZW50aWFsIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkgaXNzdWVzPw0KDQogICAgSSB0aGluayBpdCB3b3VsZCBiZSBncmVhdCB0byBhbHNv IGdldCBzb21lIHRob3VnaHRzIGZyb20gVlBODQogICAgbWFudWZhY3R1cmVycyBvbiB0aGlzIHBv aW50Lg0KDQogICAgPiBUaGF0IGlzIG5vdCB0cnVlLiBTZWN0aW9uIDMuMy4zIGxpc3RzIG1hbmRh dG9yeSB0eXBlcywgYW5kIHRob3NlDQogICAgPiBvcHRpb25hbCB0eXBlcywgd2hpY2ggYXJlIGlu Y2x1ZGVkIGluIHRoYXQgUkZDLiBJdCBkb2VzIE5PVCBsaXN0IGFueQ0KICAgID4gb2YgdGhlIGZ1 dHVyZSBvcHRpb25hbCB0eXBlcy4NCiAgICA+DQogICAgPiBJbiBzZWN0aW9uIDMuMy42IHRoaXMg aXMgZXhwbGFpbmVkIHZlcnkgY2xlYXJseToNCiAgICA+DQogICAgPiAgICBJZiB0aGUgcmVzcG9u ZGVyIHJlY2VpdmVzIGEgcHJvcG9zYWwgdGhhdCBjb250YWlucyBhIFRyYW5zZm9ybSBUeXBlDQog ICAgPiAgICBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kLCBvciBhIHByb3Bvc2FsIHRoYXQgaXMgbWlz c2luZyBhIG1hbmRhdG9yeQ0KICAgID4gICAgVHJhbnNmb3JtIFR5cGUsIGl0IE1VU1QgY29uc2lk ZXIgdGhpcyBwcm9wb3NhbCB1bmFjY2VwdGFibGU7IGhvd2V2ZXIsDQogICAgPiAgICBvdGhlciBw cm9wb3NhbHMgaW4gdGhlIHNhbWUgU0EgcGF5bG9hZCBhcmUgcHJvY2Vzc2VkIGFzIHVzdWFsLg0K ICAgID4gICAgU2ltaWxhcmx5LCBpZiB0aGUgcmVzcG9uZGVyIHJlY2VpdmVzIGEgdHJhbnNmb3Jt IHRoYXQgaXQgZG9lcyBub3QNCiAgICA+ICAgIHVuZGVyc3RhbmQsIG9yIG9uZSB0aGF0IGNvbnRh aW5zIGEgVHJhbnNmb3JtIEF0dHJpYnV0ZSBpdCBkb2VzIG5vdA0KICAgID4gICAgdW5kZXJzdGFu ZCwgaXQgTVVTVCBjb25zaWRlciB0aGlzIHRyYW5zZm9ybSB1bmFjY2VwdGFibGU7IG90aGVyDQog ICAgPiAgICB0cmFuc2Zvcm1zIHdpdGggdGhlIHNhbWUgVHJhbnNmb3JtIFR5cGUgYXJlIHByb2Nl c3NlZCBhcyB1c3VhbC4gIFRoaXMNCiAgICA+ICAgIGFsbG93cyBuZXcgVHJhbnNmb3JtIFR5cGVz IGFuZCBUcmFuc2Zvcm0gQXR0cmlidXRlcyB0byBiZSBkZWZpbmVkIGluDQogICAgPiAgICB0aGUg ZnV0dXJlLg0KICAgID4NCiAgICA+IEkuZS4sIHRoZSBpbnRlbnRpb24gaXMgdGhhdCBpZiB0aGVy ZSBpcyB0cmFuc2Zvcm0gdHlwZSB5b3UgZG8gbm90DQogICAgPiB1bmRlcnN0YW5kIHlvdSBza2lw IHdob2xlIHByb3Bvc2FsLCBidXQgU1RJTEwgUFJPQ0VTUyByZXN0IG9mIHRoZQ0KICAgID4gcHJv cG9zYWxzIG5vcm1hbGx5LCBpLmUuLCB0aGlzIGFsbG93cyBiYWNrd2FyZCBjb21wYXRpYmxpdHku DQogICAgPg0KDQogICAgWWVzLCB0aGlzIGlzIGhvdyBpdCBzaG91bGQgYmVoYXZlLg0KDQogICAg Q2hlZXJzLA0KICAgIENKDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVu dGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNz YWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdp bmFsIG1lc3NhZ2UuDQo= From nobody Thu Nov 1 04:14:23 2018 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 80000128A5C; Thu, 1 Nov 2018 04:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 SfF2-CHtNm5z; Thu, 1 Nov 2018 04:14:20 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 305FE1277D2; Thu, 1 Nov 2018 04:14:20 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id f3-v6so17687536ljk.9; Thu, 01 Nov 2018 04:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=j6Yy1fFBs8rvsm1mJrJETRJtul/FXf03XXiTo1Q0+uE=; b=kslQqTuuhnmFTNbomGf39ovQ5CCTKyoAJ00oYO6EDlxHc0cKR/ULP95ERjlic1jyVJ p20O+xIhENhqylw9xYRCVG/VZ3OlSh0n4QuWcwwquWkkR7A91k+LADoLgCUDUkJfEWN5 uWX9BMK+35bM7ZRwbGAa8rTi7+u9HYREkToU97EZnIRYL1+Z1UNgfJHPNgV/W/CE+dNU 0lbx3i3qYuoM/S4Baim0aeb6qdgHkONG6U62TsRNrY7gY9ci2gwONAqkrfKwNRdKKEwt qMesBa0g7grsceLE2vacXquQEqorrDXSLV1IpGzAQA/8/mDSTxajuE/hMAgGlRFywnyc KjhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=j6Yy1fFBs8rvsm1mJrJETRJtul/FXf03XXiTo1Q0+uE=; b=B3QCrlg7KBdQZVzDNOayuNsziYRdE83pP8PwUVD/rhF8dkqSRpuCkftLsK5V2lt54m 9STHorKZiS43xY4u22Fx9vpkub0Xvo5qj+hSZB/hftaPmOYJWUmI/ys2pG1qkwC8W1IB n4f1GR+61QtR9XBwAuJv5leF8HzOdn66NTDJ8wcGyM3cEhkcTJ/h6BtbUCw/wo4k7GRD qgeeKtT1hnh59bt92KfVhoE0u5V78LzQMb/VoFq72o3P7rJFMi2flD+i8cTRYvVgAgdY k+EgaDfASRnwmbrLl90+atd3RYJA4ZSvh5mJF70TAAVL7BFWDxZJso9MWm9n6zcIPbSq 9srA== X-Gm-Message-State: AGRZ1gKa+idlL+A3d27Ep8cOV9eWOapXlXtJH+v/bKf1zJXcjk4KB0vC vkldWDjSA4XlJkd5d6BUGnbbc0iL X-Google-Smtp-Source: AJdET5cMvrrppnHfKoXHjykLT/RXQvnbj+XyGbBOMxvB2E+gtUQJnI0TKsOclKxjaJ9Fp4QF1o3hog== X-Received: by 2002:a2e:449c:: with SMTP id b28-v6mr4450140ljf.47.1541070857752; Thu, 01 Nov 2018 04:14:17 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q124-v6sm4427505ljb.89.2018.11.01.04.14.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Nov 2018 04:14:17 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'IPsecME WG'" Cc: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> In-Reply-To: <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> Date: Thu, 1 Nov 2018 14:14:02 +0300 Message-ID: <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQBiexsmH6yYgnMQDSohT/oic8CpEgFU4nhiqBPJiHA= Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 11:14:22 -0000 Hi Scott, > > 1. Nonces. > > > > The draft specifies that each additional key exchange performed > > over IKE_AUX includes new nonces. My question - why nonces exchanged > > during IKE_SA_INIT cannot be used instead? Is it critical for security? > > No, it is not. Instead, we were (mostly) reusing the format of the CREATE_CHILD_SA request; as that request > already had nonces, we saw no specific reason to remove them. Well, I definitely don't insist, but if we reused the nonces exchanged in IKE_SA_INIT, it would have saved a few bytes on the wire :-) > > I have no problem with exchanging new nonces in each IKE_AUX, > > my concern is that while performing authentication only the nonces > > exchanged in IKE_SA_INIT are covered by the signature. For example > > for initiator: > > > > InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI > > > > where NonceRData is the content of the responder's nonce from > > IKE_SA_INIT. > > Currently IKE_AUX draft doesn't redefine this, except that it adds initiator's > > IKE_AUX content into the calculation. Is it OK, or should we modify AUTH > > payload > > calculation in case QSKE is used? In particular - include all the peer's > > nonces from IKE_AUX exchanges in NonceRData? > > Your draft includes the hash (collision resistant PRF, actually) of the aux messages in the AUX_I, which is > included in the data which is signed. Because the nonces are included in computing the AUX_I messages, we > are protected; there is no specific need to include those nonces separately. It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX messages) is included in the initiator's signature. My concern is: from my recollection of SIGMA paper it is essential for security that each party includes its peer's nonce in the signature. In case of IKE initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it is included. But the AUX_I contains only PRF over initiator's messages, i.e. it contains only initiator's additional nonces, not responder's ones. Is it OK for authentication that we don't include peer's additional nonces in the signature? Won't we screw up SIGMA? (Disclaimer: I'm not a cryptographer). > > 2. QSKE negotiation. > > > > I still think that we can use the existing negotiation mechanism instead of > > defining an additional one. I don't think we should consider the argument > > that now there are buggy implementations out there, since we're > > developing a long term solution. > > > > How it can be done with existing mechanism. > > > > First approach, classical: we define new transform types as follows: > > > > Transform Type 6: QSKE of type 1 (say lattice based) > > Transform Type 7: QSKE of type 2 (say isogeny based) > > Transform Type 8: QSKE of type 3 (say code based) > > etc. > > > > In this case list of Transform IDs for each new Transform Type will be > > different - only relevant > > algorithms must be included. In addition some QSKE Transform IDs with a > > small public key > > (regardless of type) will also be added to the list of possible Transform IDs > > for Transform Type 4. > > Minor comment on the last bit about making small public key transforms all type 4; because (with your > proposal) the responder can't accept more than one type 4 transform, that would mean that you couldn't > bundle (say) Curve25519 and SIKE (which is a small postquantum key exchange). > I would claim that is something that we would want to allow people to negotiate (as SIKE isn't necessarily well > trusted, and so it would be plausible that someone would like to negotiate Curve25519 as well). My understanding is that the crypto world is now trying to migrate to quantum-safe crypto (including key exchange). The problem is that now we don't have quantum safe key exchange methods that are fully trusted by cryptographers and have acceptable performance and public key size. For that reason we want to bundle several key exchange methods and for this purpose we need to invent that things like IKE_AUX. But I hope that in a future cryptographers will eventually invent key exchange methods that will be fully trusted and have acceptable key size, and these methods will be so good, that can even replace classic (EC)DH. If that happen, all sophisticated games with IKE_AUX will become unnecessary and we can come back to a single key exchange in IKE_SA_INIT using these new methods... So I meant that only such methods should be added to Transform Type 4. > > With this approach there's no strict mapping from QSKE to IKE_AUX, > > actually all the > > selected QSKE can be put together into single IKE_AUX exchange or can be > > performed > > one after one in a series of IKE_AUX exchanges. The latter seems more > > natural > > and is in line with current QSKE draft. Note, that KE from Transform Type 4 > > will > > always be performed in IKE_SA_INIT. If QSKEs are performed in a series of > > IKE_AUX, > > the order of them is not defined explicitly. Either we decide that the order > > is not imported > > (if it is OK from security PoV), or the order will be implicitly defined by the > > order > > of new Transform Types (6 and up) in initiator's proposal (there is no > > requirement in RFC 7296 that > > responder keep the order of Transform Types in a response). > > My issue with this general idea is backwards compatibility; if we issue a transform of type 5 to an old IKEv2 > system, it may reject the entire exchange with an "unrecognized transform type" error (and yes, there are real > systems that behave this way). > > And, it could be argued that such an IKEv2 implementation would be compliant; section 3.3.3 of RFC7296 > would appear to forbid any transform types other than 1-4 in an IKE negotiation. I think Tero has already addressed these concerns in his e-mail. > > For these reasons I think a different approach is more convenient: we > > define > > new transform types as follows: > > > > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > > etc. (How many do we want to combine?) > > > > The same list of possible Transform IDs representing QSKE methods will be > > defined > > for each of these new Transform Types. In addition these QSKE Transform > > IDs > > (or some of them with a small enough public key) will also be added to the > > list > > of possible Transform IDs for Transform Type 4. > > Why not make them all a possible transform id for type 4? After all, there are scenarios where fragmentation > is not an issue (e.g. TCP encaps) Since responder can return only a single transform of each type, this would mean that we cannot bundle several key exchanges unless new Transform Types are defined. Or do you mean that we still define new Transform Types, but make all new key exchanges available in Transform Type 4 too for the cases where fragmentation is not an issue and we don't need classic (EC)DH? > > This approach is flexible enough to define various policies: > > - don't use QSKE > > - use a single QSKE (in addition to classical KE) > > - use combination of no less than two (three, etc) QSKEs > > > > The SA payload may still grow if you want to restrict which QSKE methods > > can be combined with which ones. > > > > Comparing to the separate negotiation mechanism proposed in the draft: > > - it seems that using SA Proposals is clearer than separate mechanism > > - in case of complex policies the size of SA payload may grow, so the size > > of IKE_SA_INIT request may be larger than with the draft's negotiation > > mechanism. I still hope that we can avoid the necessity of complex > > policies, but if this is a concern, we may consider the draft > > draft-smyslov-ipsecme-ikev2-compact-04 "Compact Format of IKEv2 > > Payloads", > > which allows to substantially reduce the size of SA payload. > > > > Any thoughts? > > Now, one thing that had been bothering me with our proposal is that there is no way to include attributes > along with the transform id. Now, the existing DH/ECDH transforms do not have any attributes defined; > however some of the NIST submissions have a large number of variations (Round2 had 30 different ones), and > while we could make each variation a different transform id (which is effectively what we did with DH and > ECDH; there really is only one DH algorithm; the exact transform id selected which parameters were used with > that algorithm), however it's not clear if that's the approach we want to mandate with the newer > postquantum transforms. Using attributes will make definition of Transform ID clearer, but, as Tero pointed out, it won't help negotiation. But using attributes instead of defining a large number of Transform IDs for all possible combination of parameters looks like a good idea - at least we'll save a few bytes on the wire and a lot of lines on IANA registry page :-) > > 3. CREATE_CHILD_SA > > > > The draft currently is silent about using QSKE in CREATE_CHILD_SA > > exchange. > > Or, more specifically, using more than one keying mechanism; you can use any single KE for a > CREATE_CHILD_SA, either conventional or postquantum. > > Actually, I believe that there is some weasel working saying "you can get this effect by negotiating several child > SA's in succession"; however, I can certainly understand it if the working group decided that was not > acceptable... Do I get you right that the idea is to negotiate several successive SAs with unmodified CREATE_CHILD_SA, each with different (QS)KE methods, so that the resulting SA absorbs entropy from all the exchanges? That could work for IKE SA (rekeying), but I fail to understand how it will work for Child SAs. If you want to create new or rekey existing Child SA with additional entropy, then you cannot perform successive key exchanges unless you somehow modify CREATE_CHILD_SA exchange. Did I miss something? > > > > Initiator Responder > > ------------------------------------------------------------------- > > HDR, SK { N(ExchangeID1), N1i, QSKe1i,} --> > > <-- HDR, SK { N1r, QSKe1r, N(ExchangeID2)} > > > > HDR, SK { N(ExchangeID2), N2i, QSKe2i,} --> > > <-- HDR, SK { N2r, QSKe2r, N(ExchangeID3)} > > > > HDR, SK { N(ExchangeID3), N3i, QSKe3i,} --> > > <-- HDR, SK { N3r, QSKe3r} > > > > At this point all key are exchanged, so the SA is created. > > I suspect you'll need to be more explicit about having something tying the multiple messages together. After > all, there can be several of these exchanges going on simultaneously; it would be good to be explicit. That's what ExchangeID is for. I think it can contain some random (or only meaningful to responder) data, that helps responder to link each exchange to a previous one even if there are several in progress. It also ensures that the initiator won't start next exchange until the previous one is completed. Regards, Valery. From nobody Thu Nov 1 04:48:30 2018 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 C548A1277D2; Thu, 1 Nov 2018 04:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 N13QQDaR9Dqp; Thu, 1 Nov 2018 04:48:26 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 245B8124D68; Thu, 1 Nov 2018 04:48:26 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d7-v6so13984630lfi.2; Thu, 01 Nov 2018 04:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=d1j95wYFTKaJBXnQB0eFxxHkkqQZhV2loIZKzkSPDCk=; b=I1Tc9uilW12rHe/d7qgCz/iBtaCy6Uzoarkl1tAK5vcjL8iuCHM5R/mU3WR1WBCtw1 NoRcYNcLV2X3/xCk3cGo6qbD+1PT/mnkk8kxUWDPUc88qxfJsVLMMFmUH896bGXN/jKA /tcyz/otI8CVl/fG4BEwxg3S407bRFhYd4VBpVad2gyWDKl9UJIoBU14uvHZqW6h8QGB FF3xLkkMAnVoAkxIzLwiyBbONW2RLt/LvsFp81pT0uZZf9SY7hWhhyfXe9N00tmAOBhi hXO1LnxyhNU6usftefof/UtPdVEvFSmUAL8aOh7LXLgtZDsJs+R/cIUCNJPSYeAfLy8x kacQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=d1j95wYFTKaJBXnQB0eFxxHkkqQZhV2loIZKzkSPDCk=; b=VvrAGj8UiEspsQqLYyIujhiGQoL3KREnb1n1UIvx39gjwPpYkqcSuklRKN5YC9nLOV FOYU38g2gHaejv8ShmH+kl6g1aXSOSAWqnEY5Ip5SZ/x6ZvwEomi4A8N/P5dvkoaK2DY LfRMcVYBU8RWIT3JNyYQrJyEzA3VKexDSwkAxeiEEb8fG7a5YnKZJx4P6TlLfxTFPTEO lSrHGcbYIWz7eQmeh3smELrxPDLsQ2P8SSgYA8D9w2md11jyo8f1YvWnzIjrfc9xMzUZ GTMAo7nDGZq0b1akYiOVziTYdBd0q1Z/Mw6wyC+ohdZkCKUtNSyQoKO6h3VrTdCa6K4q Rx8Q== X-Gm-Message-State: AGRZ1gITZO52v27PP1v2hvvIeyNNrFn/nMJ/KO8lS0HNKXCz1zNZGOpz pPJws6opuHCmx3RWAIgx7KMwOK2c X-Google-Smtp-Source: AJdET5dx52Sn8bdjqjTY7o3k1Ze1vIFC/MkmxnjUpAliyCYvaQ86ZtSNtylgxbRaDviDMTlLcsJ6tw== X-Received: by 2002:a19:4948:: with SMTP id l8-v6mr3981844lfj.16.1541072904126; Thu, 01 Nov 2018 04:48:24 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id c19sm1970611lfg.86.2018.11.01.04.48.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Nov 2018 04:48:23 -0700 (PDT) From: "Valery Smyslov" To: "'CJ Tjhai'" , "'Tero Kivinen'" Cc: "'Scott Fluhrer \(sfluhrer\)'" , , References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> In-Reply-To: Date: Thu, 1 Nov 2018 14:48:08 +0300 Message-ID: <07c201d471d8$c2cdaa40$4868fec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQBiexsmH6yYgnMQDSohT/oic8CpEgFU4nhiAbjVVJkB7faSHqf22abA Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 11:48:28 -0000 Hi CJ, > > That implementation is broken, and needs to be fixed. > > What's the procedure on this? Is there a need to publish a document or > some test vectors that all implementations can validate against? > > Personally, it is more logical to introduce new transform types for > QSKEs, but one of my concerns is how can we guarantee that all broken > implementations are fixed? Of course there is no guarantee... However, as we repeated several times, this solution is not intended to be deployed in a nearest future. We don't yet even have QSKE methods that are more or less trusted by the majority of cryptographers (as far as I understand). So, vendors have plenty of time to fix their implementations and to align there with RFC. And yes, I do understand, that it doesn't mean that all customers will upgrade to a new version... On the other hand, some broken implementations can be dealt with. Just add an additional checks on initiator. > Consider the following simplified proposal: > > SA Payload > | > +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, > | | 6 transforms) > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > +-- Transform QSKE1 ( Name = Foobar ) > +-- Transform QSKE2 ( Name = Zappa ) > > At the moment, some broken implementations may abort the exchange > entirely and in some way, this helps as we may want to establish a > connection with a broken implementation. On the other hand, there > could be other implementations that ignore both QSKE1 and QSKE2 and > return a response as if there is an implicit second proposal: > | > +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, > | 4 transforms) > | > +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | +-- Attribute ( Key Length = 256 ) > +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) > +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) > +-- Transform D-H ( Name = Curve25519 ) > > So more complex checks will be required to cater for all broken cases. > I have no idea what response we will get from other broken > implementations. Yes, we can develop some checks against most obvious types of brokenness. > Or alternatively, do we have to rely on another Notification payload > to check for potential backward compatibility issues? Implementations can rely on AUX_EXCHANGE_SUPPORTED. If responder doesn't return it, then it might be broken, so restart the exchange with only classical KE methods included. > I think it would be great to also get some thoughts from VPN > manufacturers on this point. Sure. Regards, Valery. > Cheers, > CJ From nobody Thu Nov 1 08:04:24 2018 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 73769127598; Thu, 1 Nov 2018 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Nq7Tx1IHg0Zs; Thu, 1 Nov 2018 08:04:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34EC124D68; Thu, 1 Nov 2018 08:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4528; q=dns/txt; s=iport; t=1541084656; x=1542294256; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dbV7ook/7GNyFTd4agFLJwS8NCKqUq2O+8+59cRi6EI=; b=mngioU4Cx5MGK5WABAqBxTA/IwaKY5WBUkJWyKXekH4/lWIau8yV3aYa OnKyFRUOGDEFqfFma1qbHCFEHOCvy5+jZXC7LsWtyvp8OwiWFZ0MkQwEm qdZTXqE1GHaxZ8unVbdACud4HFHwQ1UMTaf9OJpsEWPvAzWmArlOx8/Xv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABfFdtb/5hdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCBIFlKAqYGoINiQKOKYF6CwEBhGwCgzsiNQw?= =?us-ascii?q?NAQMBAQIBAQJtKIU6AQEBAQIBOj8MBAIBCBEEAQEfECERHQgCBA4FCIUDAw0?= =?us-ascii?q?Iqg6HeA2CGItsF4FBP4ERgxKCVogDAokblVkuCQKNX4MhIJBTjgKJDgIRFIE?= =?us-ascii?q?mHwI0gVVwFTuCbIImF44ab4oogR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,452,1534809600"; d="scan'208";a="194367403" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2018 15:04:15 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id wA1F4EGC007929 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Nov 2018 15:04:15 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 1 Nov 2018 11:04:14 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1395.000; Thu, 1 Nov 2018 11:04:14 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen CC: Valery Smyslov , IPsecME WG , "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 Thread-Index: AQHUcW4FEF0nkpRifEa09C+frw4wp6U6Rc7w Date: Thu, 1 Nov 2018 15:04:14 +0000 Message-ID: <9313650867b44edc82256265e29d7dbb@XCH-RTP-006.cisco.com> References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> In-Reply-To: <23514.13527.860102.126373@fireball.acr.fi> 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.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.148, xch-rtp-008.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:04:18 -0000 > -----Original Message----- > From: Tero Kivinen > Sent: Wednesday, October 31, 2018 7:04 PM > To: Scott Fluhrer (sfluhrer) > Cc: Valery Smyslov ; IPsecME WG > ; draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske- > ikev2-02 >=20 > Scott Fluhrer (sfluhrer) writes: > > My issue with this general idea is backwards compatibility; if we > > issue a transform of type 5 to an old IKEv2 system, it may reject the > > entire exchange with an "unrecognized transform type" error (and yes, > > there are real systems that behave this way). >=20 > That implementation is broken, and needs to be fixed. I can easily see a manufacturer claiming "my implementation has been workin= g without a problem for 13 years; why does it need to be fixed?" Ultimately, it's the working group that needs to decide whether we need to = respect the (to the implementors) apparently valid assumption as de facto, = or whether we feel we can break them. > > > Valery: > > > For these reasons I think a different approach is more > > > convenient: we define new transform types as follows: > > > > > > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > > > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > > > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > > > etc. (How many do we want to combine?) > > > > > > The same list of possible Transform IDs representing QSKE > > > methods will be defined for each of these new Transform Types. In > > > addition these QSKE Transform IDs (or some of them with a small > > > enough public key) will also be added to the list of possible > > > Transform IDs for Transform Type 4. > > > > Why not make them all a possible transform id for type 4? After all, > > there are scenarios where fragmentation is not an issue (e.g. TCP > > encaps) >=20 > If all of them are Transform Type 4, i.e. D-H, then responder MUST pick > exactly one that is the only one to be used. Responder is not allowed ret= urn > more than one Transform ID for each Transform Type there is in proposal. I believe that you misinterpreted my question. This comment was in the con= text of Valery's proposal; in his last sentence "In addition these QSKE Tra= nsform IDs (or some of them with a small enough public keys)..." Valery sug= gested that some of the new QSKE transform id's were also to be added to th= e supported type 4 list. My query is "why not include all of them in the l= ist of valid type 4 transform types?" For that matter (I didn't express this earlier, but I'll do it now) why not= make the acceptable transform types for type 4, 6, 7, 8, etc to be exactly= the same? It would appear to me that mandating they be different (but hav= e common entries) actually adds complexity for no good reason. >=20 > > Now, one thing that had been bothering me with our proposal is that > > there is no way to include attributes along with the transform id. > > Now, the existing DH/ECDH transforms do not have any attributes > > defined; however some of the NIST submissions have a large number of > > variations (Round2 had 30 different ones), and while we could make > > each variation a different transform id (which is effectively what we > > did with DH and ECDH; there really is only one DH algorithm; the exact > > transform id selected which parameters were used with that algorithm), > > however it's not clear if that's the approach we want to mandate with > > the newer postquantum transforms. >=20 > Each Transform ID can also have arbitrary number of attributes inside, an= d > the as you can have multiple entries with same Transform Type, but either > different Transform ID or different Attributes inside, the responder can = pick > exactly one of the Transform Type of that type, and include all attribute= s > unmodified. Actually, I was making this comment in the context of "our proposal" (draft= -tjhai-ipsece-hybrid-qske-ikev2-02), which negotiates the additional KE gro= ups not within the IKE transform structure, but as 16 bit integers, and not= ing that the structure doesn't allow us to pass attributes along with the t= ransform types (which the IKE transform structure does); I was wondering ou= t loud if we would need to support attributes (which haven't been used in t= he context up until now). From nobody Thu Nov 1 08:18:08 2018 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 F32D81286D9; Thu, 1 Nov 2018 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 8aV1zMbX8BoL; Thu, 1 Nov 2018 08:18:02 -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 1C2291252B7; Thu, 1 Nov 2018 08:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12654; q=dns/txt; s=iport; t=1541085482; x=1542295082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kg+3zKnCx/mPhOFKwrBFTbH73137lqKUN9sLc6PWI0c=; b=PLOGHVQ8kGWP5l16FAKA4HTdHSeBCVdmYcSyPsmqXK5SCsr/FLL+PSWw MhKQv0bfUL8QvNunRoqFiNoDE+MNgP0lUv7g63p6YCwW/E2f7zJFExPpK 7QtigKkkir3d1KSj6ogu7j8BgdFsrZfbUDJD9uhkDHy18mC7L8yusGx44 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADNGNtb/5JdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgVoqgWUoCpgagg16iAiOKYF6CwEBhGw?= =?us-ascii?q?CgzsiNQwNAQMBAQIBAQJtKIU6AQEBAQIBOj8MBAIBCBEEAQEfECERHQgBAQQ?= =?us-ascii?q?BDQUIE4RwAw0IqhyHeA2CGIoqJYEdF4FBP4EQAYJdNYJWgk6FNQKIYymFZo9?= =?us-ascii?q?cJi4JAo1fgyEgkFOOAokOAhEUgSYeATaBVXAVO4JsgiMCARd9AQKNGm+KKIE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.54,452,1534809600"; d="scan'208";a="474445263" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2018 15:17:59 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wA1FHxUX016794 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Nov 2018 15:17:59 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 1 Nov 2018 11:17:58 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1395.000; Thu, 1 Nov 2018 11:17:58 -0400 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "'IPsecME WG'" CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 Thread-Index: AdRxISFkud4inQZOTYCMbnQCiNECBQABjTEgADOL0QAAAcPNMA== Date: Thu, 1 Nov 2018 15:17:58 +0000 Message-ID: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> In-Reply-To: <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.149, xch-rtp-009.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:18:06 -0000 > -----Original Message----- > From: Valery Smyslov > Sent: Thursday, November 01, 2018 7:14 AM > To: Scott Fluhrer (sfluhrer) ; 'IPsecME WG' > > Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > Subject: RE: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 >=20 > Hi Scott, >=20 > > > 1. Nonces. > > > > > > The draft specifies that each additional key exchange performed > > > over IKE_AUX includes new nonces. My question - why nonces > exchanged > > > during IKE_SA_INIT cannot be used instead? Is it critical for sec= urity? > > > > No, it is not. Instead, we were (mostly) reusing the format of the > > CREATE_CHILD_SA request; as that request already had nonces, we saw no > specific reason to remove them. Correction to what I said: the original reasoning was not to keep the IKE m= essage format, but rather to reuse the IKE child SA key derivation function= (section 2.17) >=20 > Well, I definitely don't insist, but if we reused the nonces exchanged in > IKE_SA_INIT, it would have saved a few bytes on the wire :-) Ultimately, I don't believe it matters all that much... >=20 > > > I have no problem with exchanging new nonces in each IKE_AUX, > > > my concern is that while performing authentication only the nonce= s > > > exchanged in IKE_SA_INIT are covered by the signature. For exampl= e > > > for initiator: > > > > > > InitiatorSignedOctets =3D RealMessage1 | NonceRData | MACedIDForI > > > > > > where NonceRData is the content of the responder's nonce from > > > IKE_SA_INIT. > > > Currently IKE_AUX draft doesn't redefine this, except that it add= s > initiator's > > > IKE_AUX content into the calculation. Is it OK, or should we > > > modify AUTH payload > > > calculation in case QSKE is used? In particular - include all the= peer's > > > nonces from IKE_AUX exchanges in NonceRData? > > > > Your draft includes the hash (collision resistant PRF, actually) of > > the aux messages in the AUX_I, which is included in the data which is > > signed. Because the nonces are included in computing the AUX_I > messages, we are protected; there is no specific need to include those > nonces separately. >=20 > It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX me= ssages) > is included in the initiator's signature. > My concern is: from my recollection of SIGMA paper it is essential for se= curity > that each party includes its peer's nonce in the signature. In case of IK= E > initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it = is > included. > But the AUX_I contains only PRF over initiator's messages, i.e. it contai= ns only > initiator's additional nonces, not responder's ones. > Is it OK for authentication that we don't include peer's additional nonce= s in > the signature? Won't we screw up SIGMA? > (Disclaimer: I'm not a cryptographer). The nonces are included; however instead of including the text of the nonce= directly, we're including a complex function of (among other things) the n= onces. If you change the nonces, you change the output of that complex fun= ction, which changes the text of what is signed, and that is what SIGMA rel= ies on. >=20 > > > 2. QSKE negotiation. > > > > > > I still think that we can use the existing negotiation mechanism i= nstead > of > > > defining an additional one. I don't think we should consider the > argument > > > that now there are buggy implementations out there, since we're > > > developing a long term solution. > > > > > > How it can be done with existing mechanism. > > > > > > First approach, classical: we define new transform types as follo= ws: > > > > > > Transform Type 6: QSKE of type 1 (say lattice based) > > > Transform Type 7: QSKE of type 2 (say isogeny based) > > > Transform Type 8: QSKE of type 3 (say code based) > > > etc. > > > > > > In this case list of Transform IDs for each new Transform Type > > > will be different - only relevant > > > algorithms must be included. In addition some QSKE Transform IDs > > > with a small public key > > > (regardless of type) will also be added to the list of possible > > > Transform IDs for Transform Type 4. > > > > Minor comment on the last bit about making small public key transforms > > all type 4; because (with your > > proposal) the responder can't accept more than one type 4 transform, > > that would mean that you couldn't bundle (say) Curve25519 and SIKE > (which is a small postquantum key exchange). > > I would claim that is something that we would want to allow people to > > negotiate (as SIKE isn't necessarily well trusted, and so it would be p= lausible > that someone would like to negotiate Curve25519 as well). >=20 > My understanding is that the crypto world is now trying to migrate to > quantum-safe crypto (including key exchange). > The problem is that now we don't have quantum safe key exchange > methods that are fully trusted by cryptographers and have acceptable > performance and public key size. For that reason we want to bundle severa= l > key exchange methods and for this purpose we need to invent that things > like IKE_AUX. But I hope that in a future cryptographers will eventually = invent > key exchange methods that will be fully trusted and have acceptable key > size, and these methods will be so good, that can even replace classic (E= C)DH. > If that happen, all sophisticated games with IKE_AUX will become > unnecessary and we can come back to a single key exchange in IKE_SA_INIT > using these new methods... So I meant that only such methods should be > added to Transform Type 4. Given that we don't know which such methods would eventually meet this fina= l criteria of "usable only by itself", I would expect that we would be well= advised to include everything on the list. Even in cases of methods with = moderately large key shares (e.g. Frodo), there are times that IKE doesn't = care about fragmentation (e.g. TCP encaps), and in those cases, it might ve= ry well be considered a viable option by itself. In addition, you essentially gave two proposals; one where transform type 6= meant "Lattice Based", and another proposal where transform type 6 meant "= whatever key exchange we're doing in the first IKE AUX exchange". Of those two proposals, I would personally vote for the second one; it woul= d appear to me to be cleaner (of course, I would still prefer the tjhai pro= posal to either...) >=20 > > > For these reasons I think a different approach is more > > > convenient: we define > > > new transform types as follows: > > > > > > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > > > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > > > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > > > etc. (How many do we want to combine?) > > > > > > The same list of possible Transform IDs representing QSKE > > > methods will be defined > > > for each of these new Transform Types. In addition these QSKE > > > Transform IDs > > > (or some of them with a small enough public key) will also be > > > added to the list > > > of possible Transform IDs for Transform Type 4. > > > > Why not make them all a possible transform id for type 4? After all, > > there are scenarios where fragmentation is not an issue (e.g. TCP > > encaps) >=20 > Since responder can return only a single transform of each type, this wou= ld > mean that we cannot bundle several key exchanges unless new Transform > Types are defined. >=20 > Or do you mean that we still define new Transform Types, but make all new > key exchanges available in Transform Type 4 too for the cases where > fragmentation is not an issue and we don't need classic (EC)DH? The latter (still define new Transform Types, but also make all new key exc= hanges available); I see no specific reason to restrict things unnecessaril= y... >=20 > > > This approach is flexible enough to define various policies: > > > - don't use QSKE > > > - use a single QSKE (in addition to classical KE) > > > - use combination of no less than two (three, etc) QSKEs > > > > > > The SA payload may still grow if you want to restrict which QSKE > methods > > > can be combined with which ones. > > > > > > Comparing to the separate negotiation mechanism proposed in the > draft: > > > - it seems that using SA Proposals is clearer than separate mechan= ism > > > - in case of complex policies the size of SA payload may grow, so = the size > > > of IKE_SA_INIT request may be larger than with the draft's negot= iation > > > mechanism. I still hope that we can avoid the necessity of compl= ex > > > policies, but if this is a concern, we may consider the draft > > > draft-smyslov-ipsecme-ikev2-compact-04 "Compact Format of IKEv2 > > > Payloads", > > > which allows to substantially reduce the size of SA payload. > > > > > > Any thoughts? > > > > Now, one thing that had been bothering me with our proposal is that > > there is no way to include attributes along with the transform id. > > Now, the existing DH/ECDH transforms do not have any attributes > > defined; however some of the NIST submissions have a large number of > > variations (Round2 had 30 different ones), and while we could make > > each variation a different transform id (which is effectively what we > > did with DH and ECDH; there really is only one DH algorithm; the exact > transform id selected which parameters were used with that algorithm), > however it's not clear if that's the approach we want to mandate with the > newer postquantum transforms. >=20 > Using attributes will make definition of Transform ID clearer, but, as Te= ro > pointed out, it won't help negotiation. > But using attributes instead of defining a large number of Transform IDs = for > all possible combination of parameters looks like a good idea - at least = we'll > save a few bytes on the wire and a lot of lines on IANA registry page :-) Actually, I believe using attributes (rather than distinct transform ids) w= ould add to the payload size (but only slightly). For example, instead of: +-- Transform D-H ( Name =3D NTRU_3 ) We might have +-- Transform D-H ( Name =3D NTRU ) +-- Attribute ( Security Level =3D 3 ) (The "security level" attribute is just what immediately occurred to me; I = don't know what actual attribute would make sense...) In any case, I was just wondering whether we would use attributes as a part= of the negotiation (and I suspect that we don't know yet); if we do, that = would put the tjhai proposal at a disadvantage... >=20 > > > 3. CREATE_CHILD_SA > > > > > > The draft currently is silent about using QSKE in > > > CREATE_CHILD_SA exchange. > > > > Or, more specifically, using more than one keying mechanism; you can > > use any single KE for a CREATE_CHILD_SA, either conventional or > postquantum. > > > > Actually, I believe that there is some weasel working saying "you can > > get this effect by negotiating several child SA's in succession"; > > however, I can certainly understand it if the working group decided tha= t > was not acceptable... >=20 > Do I get you right that the idea is to negotiate several successive SAs w= ith > unmodified CREATE_CHILD_SA, each with different (QS)KE methods, so that > the resulting SA absorbs entropy from all the exchanges? > That could work for IKE SA (rekeying), but I fail to understand how it wi= ll work > for Child SAs. If you want to create new or rekey existing Child SA with > additional entropy, then you cannot perform successive key exchanges > unless you somehow modify CREATE_CHILD_SA exchange. Did I miss > something? Actually, the original idea was cruder than that; suppose you wanted to rek= ey an IPsec SA, and you used three key exchange methods. What you would do= is: - First create a child IKE SA (using keying mechanism 1); this would replac= e the original IKE SA - Then, create a second child IKE SA (using keying mechanism 2); this would= replace IKE SA that you just created - Finally, create children IPsec SAs (using keying mechanism 3) As I said earlier, I could certainly understand it if the WG decided that t= his was unacceptable... From nobody Thu Nov 1 11:42:38 2018 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 BA483128A6E for ; Thu, 1 Nov 2018 11:42:36 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bZLMnf_xRK7J for ; Thu, 1 Nov 2018 11:42:32 -0700 (PDT) Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F928124BAA for ; Thu, 1 Nov 2018 11:42:31 -0700 (PDT) From: "Hammell, Jonathan F" To: "'ipsec@ietf.org'" Thread-Topic: Verification of IKEv2 PPK Thread-Index: AdRyEdEAKPTdpk+ASB+1RAcLuzulbg== Date: Thu, 1 Nov 2018 18:42:36 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-classification: UNCLASSIFIED Content-Type: multipart/mixed; boundary="_003_58976649956f45ed8f81214ee4468978cybergcca_" MIME-Version: 1.0 Message-Id: <20181101184231.7F928124BAA@ietfa.amsl.com> Archived-At: Subject: [IPsec] Verification of IKEv2 PPK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 18:42:37 -0000 --_003_58976649956f45ed8f81214ee4468978cybergcca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Researchers at the Canadian Centre for Cyber Security (CCCS) have modeled t= he state machine of the IKEv2 PPK I-D draft-ietf-ipsecme-qr-ikev2-04 in ord= er to verify the logic. =20 The attached file qr_ppk_responder.smv contains a model written for NuSMV (= http://nusmv.fbk.eu) of an asynchronous finite-state machine modelling the = responder role described in the I-D. The file also contains CTL specificati= ons of the 7 conditions presented in the table on page 8 of the draft. To run, please install a recent version of NuSMV and run the command ./NuSMV qr_ppk_responder.smv The output shows the results of the application of the CTL specifications t= o the model.=20 We also include several CTL sanity checks for the model, but they are curre= ntly disabled in order to be clear about the claims. Comments about the implementation of the draft: The table on page 8 was found to be essential in developing a working model= . Several of the table conditions needed some interpretation and we hope ou= rs is correct. "Have PPK" =20 Our interpretation was that "Have PPK" specifies whether a Responder shared= a valid PPK with an Initiator. We noted that in order for determination to= be made whether he did nor not, the Responder would first need to receive = an ID either in the PPK_IDENTITY notification or from the IDi payload (if c= onfigured to do so), and then check whether the ID was known and if it was = whether or not a PPK was configured for this ID.=20 In our implementation for example, we modelled that a Responder shared a PP= K with the initiator with the condition: NOTIFY.PPK_ID =3D TRUE & VERIFY.PPK_ID_KNOWN =3DTRUE=20 Which states that a PPK_ID notify was received and that the ID from the not= ify was known=20 Equivalently he could use the ID from the Idi payload if configured appropr= iately, which is expressed as follows NOTIFY.PPK_ID =3D TRUE & VERIFY.PPK_ID_KNOWN =3D FALSE & VERIFY.PAYLOAD_ID= _KNOWN =3D TRUE & CONFIG.USE_ID_PAYLOAD =3D TRUE=20 In both cases after a successful ID check, they will then check whether the= y actually share a PPK i.e=20 VERIFY.HAVE_PPK =3D TRUE "PPK Mandatory" Our interpretation is that PPK Mandatory limits successful completion of th= e handshake to cases where the parties share a PPK, in this case no downgra= de is possible.=20 The check occurs after a successful ID check and at the same time as the ch= eck to see if they share a PPK. If it is mandatory, the only non-error path= is when they share a PPK. CONFIG.PPK_MANDATORY =3D TRUE & VERIFY.HAVE_PPK =3D TRUE If you have comments/questions, reply to the list or we can chat in Bangkok= . Jonathan Hammell Canadian Centre for Cyber Security https://cyber.gc.ca --_003_58976649956f45ed8f81214ee4468978cybergcca_ Content-Type: application/octet-stream; name="qr_ppk_responder.smv" Content-Description: qr_ppk_responder.smv Content-Disposition: attachment; filename="qr_ppk_responder.smv"; size=13225; creation-date="Thu, 01 Nov 2018 18:37:05 GMT"; modification-date="Thu, 01 Nov 2018 16:38:27 GMT" Content-Transfer-Encoding: base64 TU9EVUxFIENvbmZpZygpIC0tIGNvbmZpZ3VyYXRpb24gc2V0dGluZ3MgZm9yIFBQSw0KIFZBUiBQ UEtfTUFOREFUT1JZOiBib29sZWFuOyAtLSBJbml0aWF0b3ItUmVzcG9uZGVyIHBhaXIgaGF2ZSBQ UEsgY29uZmlndXJlZCAgYXMgbWFuZGF0b3J5DQogVkFSIFVTRV9JRF9QQVlMT0FEIDogYm9vbGVh bjsgLS0gdXNlIElEIGZyb20gSUQgcGF5bG9hZCBpbnN0ZWFkIG9mIFBQS19JRCBub3RpZmljYXRp b24NCiBWQVIgQVVUSF9UWVBFIDogeyBQUEtfT05MWSwgUkVHVUxBUn07IC0tIG9uZSBvZiB0d28g YXV0aGVudGljYXRpb24gbWV0aG9kcyBjYW4gYmUgY29uZmlndXJlZCAsIFJFR1VMQVIgd291bGQg YmUgUlNBIHNpZ25pbmcgZm9yIGV4YW1wbGUNCg0KQVNTSUdODQogDQogbmV4dChQUEtfTUFOREFU T1JZKSA6PSBQUEtfTUFOREFUT1JZOw0KIG5leHQoVVNFX0lEX1BBWUxPQUQpIDo9IFVTRV9JRF9Q QVlMT0FEOw0KIG5leHQoQVVUSF9UWVBFKSA6PSBBVVRIX1RZUEU7DQogDQoNCg0KIC0tdGhlc2Ug YXJlIDQgZGlmZmVyZW50IHZlcmlmaWNhdGlvbiBhY3Rpb25zIHdlIGlkZW50aWZpZWQNCg0KTU9E VUxFIFZlcmlmeSgpIA0KIFZBUiBIQVZFX1BQSyA6IGJvb2xlYW47ICAtLSBkbyBwZWVycyBzaGFy ZSBhIFBQSw0KIFZBUiBQUEtfSURfS05PV046Ym9vbGVhbjsgIC0tIGlzIHRoZSBJRCBpbiB0aGUg UFBLX0lERU5USVRZIGtub3duIHRvIHRoZSByZXNwb25kZXINCiBWQVIgUEFZTE9BRF9JRF9LTk9X TiA6IGJvb2xlYW47ICAtLSBpcyB0aGUgSUQgaW4gdGhlIElEaSBwYXlsb2FkIGtub3duDQogVkFS IEFVVEhfVkVSSUZJRVMgOiBib29sZWFuOyAgIC0tIGRpZCB0aGUgQVVUSCBwYXlsb2FkIHZlcmlm eSBvciBub3QNCg0KQVNTSUdODQogLS1pbml0KEhBVkVfUFBLKSA6PSBGQUxTRTsNCiAtLWluaXQo UFBLX0lEX0tOT1dOKSA6PSBGQUxTRTsNCiAtLWluaXQoUEFZTE9BRF9JRF9LTk9XTikgOj0gRkFM U0U7DQogLS1pbml0KEFVVEhfVkVSSUZJRVMpIDo9IEZBTFNFOw0KIG5leHQoSEFWRV9QUEspIDo9 IEhBVkVfUFBLOw0KIG5leHQoUFBLX0lEX0tOT1dOKSAgOj0gUFBLX0lEX0tOT1dOOw0KIG5leHQo QVVUSF9WRVJJRklFUykgOj0gQVVUSF9WRVJJRklFUzsNCiBuZXh0KFBBWUxPQURfSURfS05PV04p IDo9UEFZTE9BRF9JRF9LTk9XTjsNCg0KLS0gd2UgIG1vZGVsIG9ubHkgMiBhdXRoZW50aWNhdGlv biBtZXRob2RzIGluIHRoZSBJS0VfU0FfSU5JVCBtZXNzYWdlDQpNT0RVTEUgSUtFX1NBX0lOSVRf TUVTUygpDQogVkFSIE5FR19QUEtfT05MWV9BVVRIIDogYm9vbGVhbjsNCiBWQVIgTkVHX1JFR1VM QVJfQVVUSCA6IGJvb2xlYW47DQogDQpBU1NJR04NCiBuZXh0KE5FR19QUEtfT05MWV9BVVRIKSA6 PSBORUdfUFBLX09OTFlfQVVUSDsNCiBuZXh0KE5FR19SRUdVTEFSX0FVVEgpIDo9IE5FR19SRUdV TEFSX0FVVEg7DQogDQotLSB3ZSBtb2RlbCB0aGUgQVVUSCBwYXlsb2FkIG9mIHR3byB0eXBlcyBQ UEstb25seSBvciBSRUdVTEFSDQpNT0RVTEUgSUtFX0FVVEhfTUVTUygpDQogVkFSIFBQS19PTkxZ X0FVVEggOiBib29sZWFuOw0KIFZBUiBSRUdfQVVUSDogYm9vbGVhbjsNCg0KQVNTSUdODQogbmV4 dChQUEtfT05MWV9BVVRIKSA6PSBQUEtfT05MWV9BVVRIOw0KIG5leHQoUkVHX0FVVEgpIDo9IFJF R19BVVRIOw0KDQotLXRoZXNlIGFyZSB0aGUgbm90aWZpY2F0aW9uIHBheWxvYWRzICh3aGV0aGVy IHByZXNlbnQgb3IgIG5vdCkNCk1PRFVMRSBOT1RJRlkoKSANCiBWQVIgVVNFX1BQSyA6IGJvb2xl YW47DQogVkFSIFBQS19JRCA6IGJvb2xlYW47DQogVkFSIE5PX1BQS19BVVRIIDogYm9vbGVhbjsN CiBWQVIgQVVUSF9GQUlMOiBib29sZWFuOw0KIFZBUiBFUlJPUiA6IGJvb2xlYW47DQoNCkFTU0lH Tg0KIC0taW5pdChVU0VfUFBLKSA6PSBGQUxTRTsNCiAtLWluaXQoUFBLX0lEKSA6PSBGQUxTRTsN CiAtLWluaXQoTk9fUFBLX0FVVEgpIDo9IEZBTFNFOw0KIC0taW5pdChBVVRIX0ZBSUwpIDo9IEZB TFNFOw0KIG5leHQoVVNFX1BQSykgOj0gVVNFX1BQSzsNCiBuZXh0KFBQS19JRCkgOj0gUFBLX0lE Ow0KIG5leHQoTk9fUFBLX0FVVEgpIDo9IE5PX1BQS19BVVRIOw0KIG5leHQoQVVUSF9GQUlMKSA6 PSBBVVRIX0ZBSUw7DQogbmV4dChFUlJPUikgOj0gRVJST1I7DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KTU9EVUxFIG1haW4NCg0KLS0xNiBzdGF0ZSBtb2RlbCwgdHJhbnNs YXRlIHRvIHNvbWV0aGluZyBsaWtlDQotLSBxMCA6IEluaXQgOiByZWNlaXZlIElLRV9TQV9JTklU IGNoZWNrIGZvciBVU0VfUFBLIG5vdGlmaWNhdGlvbiAocTEgb3IgcTE0KQ0KLS0gcTEgOiBjaGVj ayBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIElLRV9TQV9JTklUIC0gUFBLLW9ubHkgb3IgUmVn dWxhciAocTIgb3IgcTMpDQotLSBxMiA6IGNhc2UgUFBLLW9ubHkgYXV0aCA6IGNoZWNrIGZvciB2 YWxpZCAgSUQgaW4gSUtFX0FVVEggIChxOCkNCi0tIHEzIDogY2FzZSBQUEsgd2l0aCBSZWd1bGFy IGF1dGggOiBjaGVjayBmb3IgdmFsaWQgIElEIGluIElLRV9BVVRIICAocTkgKQ0KLS0gcTggOiBQ UEstb25seSA6IGNoZWNrIGZvciBtYW5kYXRvcnkgYW5kIHRoYXQgdGhleSBzaGFyZSBQUEsgKHEx MikNCi0tIHE5IDogUmVndWxhciBhdXRoOiBjaGVjayBpZiB0aGV5IHNoYXJlIFBQSyAocTEyIG9y IHExMCkNCi0tIHExMCA6IG5vIFBQSyBkb3duZ3JhZGUgd2l0aCBOT19QUEtfQVVUSCBub3RpZmlj YXRpb246IGNoZWNrIHdoZXRoZXIgbWFuZGF0b3J5IG9yIG5vdCAocTE3KQ0KLS0gcTExIDogUmVn dWxhciBhdXRoIHNoYXJlIFBQSzogIHZlcmlmeSBhdXRoZW50aWNhdGlvbiAocTIxKQ0KLS0gcTEy IDogUFBLLW9ubHkgYXV0aDogIHZlcmlmeSBhdXRoZW50aWNhdGlvbiAocTIwKQ0KLS0gcTE0IDog Y2FzZSBubyBQUEsgKGRpZCBub3QgcmVjZWl2ZSBhIFVTRV9QUEsgaW4gSUtFX1NBX0lOSVQpIDog IGNoZWNrIGF1dGggbWV0aG9kIChxMTUpDQotLSBxMTUgOiBubyBQUEsgd2l0aCAgY29ycmVjdCBh dXRoZW50aWNhdGlvbiBtZXRob2Q6IGNoZWNrIElEIGluIElLRV9BVFVIIHRvIG1ha2Ugc3VyZSBQ UEsgbm90IG1hbmRhdG9yeSAocTE3KQ0KLS0gcTE3IDogbm8gUFBLIHJlZ3VsYXIgYXV0aCA6IHZl cmlmeSBhdXRoZW50aWNhdGlvbiAocTIyKQ0KLS0gcTIwIDogUFBLLW9ubHkgYXV0aDogQ3JlYXRl IENoaWxkIFNBDQotLSBxMjEgOiBQUEsgcmVndWxhciBhdXRoIDogY3JlYXRlIENoaWxkIFNBDQot LSBxMjIgOiBubyBQUEsgcmVndWxhciBhdXRoIDogY3JlYXRlIENoaWxkIFNBDQotLSBxMTMgOiBF UlJPUiBxMTMNCg0KVkFSIHN0YXRlIDp7cTAscTEscTIscTMscTYscTcsIHE4LCBxOSxxMTAscTEx LHExMiwgcTEzLHExNCxxMTUsIHExNixxMTcscTIwLHEyMSxxMjJ9Ow0KDQpWQVIgQ09ORklHOiBD b25maWcoKTsNClZBUiBWRVJJRlk6IFZlcmlmeSgpOw0KVkFSIElLRVNBSU5JVDogSUtFX1NBX0lO SVRfTUVTUygpOw0KVkFSIElLRUFVVEg6IElLRV9BVVRIX01FU1MoKTsNClZBUiBOT1RJRlk6IE5P VElGWSgpOw0KDQoNCi0tIHdlIGRpZCBub3QgbW9kZWwgdGhlIFJlc3BvbmRlciBvdXRwdXQgaW4g dGhpcyBtb2RlbA0KLS1vdXQ6IHtOVUxMLCBVU0VfUFBLX05FR19OVUxMX0FVVEgsVVNFX1BQS19O RUdfUkVHX0FVVEgsIE5VTExfTkVHX1JFR19BVVRILCAgTlVMTF9BVVRILCBOVUxMX05VTEwsIENI SUxEX1NBLCBBQk9SVCxOT1RJRllfQVVUSF9GQUlMLCBQUEtfUkVHQVVUSF9DSElMRF9TQSxQUEtf Q0hJTERfU0EsIE5vTUVTUywgUkVHVUxBUl9BVVRILCBQUEtfSURfUFBLX0FVVEgsIFBQS19JRF9S RUdfQVVUSCwgTlVMTF9SRUdfQVVUSH07DQoNCg0KDQpBU1NJR04gDQoNCmluaXQoc3RhdGUpIDo9 cTA7DQoNCg0KbmV4dChzdGF0ZSkgOj0gDQogICAgY2FzZQ0KDQogICAtLSB2ZXJpZnkgY29udGVu dCBvZiBJS0VfU0FfSU5JVCBtZXNzYWdlDQogICBzdGF0ZSA9IHEwICYgTk9USUZZLlVTRV9QUEsg PSBUUlVFICAgICA6IHExOyAgLS0gcG90ZW50aWFsIGZvciBQUEsNCiAgIHN0YXRlID0gcTAgJiBO T1RJRlkuVVNFX1BQSyA9IEZBTFNFICAgIDogcTE0OyAtLSBjb250aW51ZSB3aXRob3V0IFBQSw0K ICAgDQogICANCiAgDQogICAtLSBjaGVja3MgYXV0aGVudGljYXRpb24gbWV0aG9kIHNlbnQgaW4g dGhlIEluaXRpYXRvcnMgSUtFX1NBX0lOSVQgYW5kIHNlbmRzIGFuIElLRV9TQV9JTklUIG9mIHRo ZSBhcHByb3ByaWF0ZSBraW5kDQogICANCiAgIHN0YXRlID0gcTEgJiBJS0VTQUlOSVQuTkVHX1BQ S19PTkxZX0FVVEggPSBGQUxTRSAmIElLRVNBSU5JVC5ORUdfUkVHVUxBUl9BVVRIID0gRkFMU0U6 IHExMzsNCiAgIC0tIFBQSy1PTkxZDQogICBzdGF0ZSA9IHExICYgSUtFU0FJTklULk5FR19QUEtf T05MWV9BVVRIID0gVFJVRSAmIENPTkZJRy5BVVRIX1RZUEUgPSBQUEtfT05MWSA6IHEyOw0KICAg c3RhdGUgPSBxMSAmIElLRVNBSU5JVC5ORUdfUFBLX09OTFlfQVVUSCA9IFRSVUUgJiBDT05GSUcu QVVUSF9UWVBFID0gUkVHVUxBUiAgOiBxMTM7DQogICAtLSBQUEsgd2l0aCBzdGFuZGFyZCAoY2Fs bGluZyBpdCBSRUdVTEFSIGhlcmUgISkNCiAgIHN0YXRlID0gcTEgJiBJS0VTQUlOSVQuTkVHX1JF R1VMQVJfQVVUSCAgPSBUUlVFICYgQ09ORklHLkFVVEhfVFlQRSA9IFJFR1VMQVIgIDogcTM7DQog ICBzdGF0ZSA9IHExICYgSUtFU0FJTklULk5FR19SRUdVTEFSX0FVVEggID0gVFJVRSAmIENPTkZJ Ry5BVVRIX1RZUEUgPSBQUEtfT05MWSAgOiBxMTM7DQoNCiAgIC0tIG5vIFBQSyB3aXRoIHN0YW5k YXJkDQogICBzdGF0ZSA9IHExNCAmIElLRVNBSU5JVC5ORUdfUkVHVUxBUl9BVVRIICA9IFRSVUUg JiBDT05GSUcuQVVUSF9UWVBFID0gUkVHVUxBUiA6IHExNTsNCiAgIHN0YXRlID0gcTE0ICYgKElL RVNBSU5JVC5ORUdfUkVHVUxBUl9BVVRIICA9IEZBTFNFIHwgQ09ORklHLkFVVEhfVFlQRSA9IFBQ S19PTkxZKSA6IHExMzsNCg0KDQogICAgLS0gcmVjZXB0aW9uIG9mIHRoZSBJS0VfQVVUSCAgLSBm aXJzdCBzdGVwIGlzIHRvIGNoZWNrIGZvciB2YWxpZCBJRHMNCiAgIA0KICAgIC0tIFN0YXRlIHEy IDogUFBLIHdpdGggUFBLLU9OTFkgYXV0aGVudGljYXRpb24NCiAgICAtLSB3ZSBhc3N1bWUgd2Ug bmVlZCB0byByZWNlaXZlIGEgUFBLX0lEIG5vdGlmaWNhdGlvbg0KDQogICAgIC0tIGZpcnN0IGNo ZWNrIGlmIHdlIGhhdmUgdmFsaWQgSUQgb3Igbm90IC0gbm8gZG93bmdyYWRlIHBvc3NpYmxlDQog ICAgIHN0YXRlID0gcTIgICYgTk9USUZZLlBQS19JRCA9IFRSVUUgJiBWRVJJRlkuUFBLX0lEX0tO T1dOID0gVFJVRSA6IHE4Ow0KICAgICBzdGF0ZSA9IHEyICYgTk9USUZZLlBQS19JRCA9IFRSVUUg JiBWRVJJRlkuUFBLX0lEX0tOT1dOID0gRkFMU0UgJiBDT05GSUcuVVNFX0lEX1BBWUxPQUQgPSBU UlVFICYgVkVSSUZZLlBBWUxPQURfSURfS05PV04gPSBUUlVFIDogcTg7DQogICAgIC0tIG5lZWQg YSB2YWxpZCBJRCB0byBjb250aW51ZQ0KICAgICBzdGF0ZSA9IHEyICYgTk9USUZZLlBQS19JRCA9 IFRSVUUgJiAoIFZFUklGWS5QUEtfSURfS05PV04gPSBGQUxTRSAmIENPTkZJRy5VU0VfSURfUEFZ TE9BRCA9IFRSVUUgJiBWRVJJRlkuUEFZTE9BRF9JRF9LTk9XTiA9IEZBTFNFKSA6IHExMzsNCiAg ICAgc3RhdGUgPSBxMiAmIE5PVElGWS5QUEtfSUQgPSBUUlVFICYgKCBWRVJJRlkuUFBLX0lEX0tO T1dOID0gRkFMU0UgJiAgQ09ORklHLlVTRV9JRF9QQVlMT0FEID0gRkFMU0UpIDogcTEzOw0KICAg ICBzdGF0ZSA9IHEyICYgTk9USUZZLlBQS19JRCA9IEZBTFNFOiBxMTM7DQogICAgIA0KIA0KICAg IA0KICAgIA0KICAgLS0gQ0FTRTogUFBLIHdpdGggUkVHVUxBUiBBVVRIIA0KDQogICAgLS0gZmly c3QgY2hlY2sgZm9yIGEgdmFsaWQgSUQNCiAgICANCiAgICBzdGF0ZSA9IHEzICYgTk9USUZZLlBQ S19JRCA9IFRSVUUgJiBWRVJJRlkuUFBLX0lEX0tOT1dOID0gVFJVRSAgIDogcTk7DQogICAgc3Rh dGUgPSBxMyAmIE5PVElGWS5QUEtfSUQgPSBUUlVFICYgVkVSSUZZLlBQS19JRF9LTk9XTiA9IEZB TFNFICYgQ09ORklHLlVTRV9JRF9QQVlMT0FEID0gVFJVRSAmICBWRVJJRlkuUEFZTE9BRF9JRF9L Tk9XTiA9IFRSVUUgIDogcTk7DQogICAgc3RhdGUgPSBxMyAmIE5PVElGWS5QUEtfSUQgPSBGQUxT RSA6IHExMzsNCiAgICBzdGF0ZSA9IHEzICYgTk9USUZZLlBQS19JRCA9IFRSVUUgJiBWRVJJRlku UFBLX0lEX0tOT1dOID0gRkFMU0UgJiBDT05GSUcuVVNFX0lEX1BBWUxPQUQgPSBGQUxTRSAgOiBx MTM7DQoNCiAgICANCg0KICAgIC0tIGNoZWNrIHRoYXQgd2UgaGF2ZSBQUEsgYmVmb3JlIG1vdmlu ZyBvbiwgaWYgd2UgZG9uJ3QsIGxvb2sgZm9yIE5PX1BQS19BVVRIDQoNCiAgICBzdGF0ZSA9IHE5 ICYgVkVSSUZZLkhBVkVfUFBLID0gVFJVRSA6IHExMTsNCiAgICBzdGF0ZSA9IHE5ICYgVkVSSUZZ LkhBVkVfUFBLID0gRkFMU0UgJiBOT1RJRlkuTk9fUFBLX0FVVEggPSBGQUxTRSA6IHExMzsNCiAg ICBzdGF0ZSA9IHE5ICYgVkVSSUZZLkhBVkVfUFBLID0gRkFMU0UgJiBOT1RJRlkuTk9fUFBLX0FV VEggPSBUUlVFIDogcTEwOw0KDQogICAgIC0tIGNhbiBjb250aW51ZSB3aXRob3V0IGEgdmFsaWQg SUQgaWYgd2UgcmVjZWl2ZSBhIE5PX1BQS19BVVRIIC0gcG9zc2libGUgZG93bmdyYWRlDQoNCg0K ICAgICBzdGF0ZSA9IHEzICYgTk9USUZZLlBQS19JRCA9IFRSVUUgJiAoIFZFUklGWS5QUEtfSURf S05PV04gPSBGQUxTRSAmIENPTkZJRy5VU0VfSURfUEFZTE9BRCA9IEZBTFNFICYgVkVSSUZZLlBB WUxPQURfSURfS05PV04gPSBUUlVFKSAmIE5PVElGWS5OT19QUEtfQVVUSCA9IFRSVUUgIDogcTEw Ow0KDQogICAgLS0gc3RhdGUgPSBxMyAmIE5PVElGWS5QUEtfSUQgPSBUUlVFICYgKCBWRVJJRlku UFBLX0lEX0tOT1dOID0gVFJVRSAmIFZFUklGWS5IQVZFX1BQSyA9IEZBTFNFKSAmIE5PVElGWS5O T19QUEtfQVVUSCA9IFRSVUUgIDogcTEwOw0KDQogICAgIC0tc3RhdGUgPSBxMyAmIE5PVElGWS5Q UEtfSUQgPSBUUlVFICYgKCBDT05GSUcuVVNFX0lEX1BBWUxPQUQgPSBUUlVFICYgVkVSSUZZLlBB WUxPQURfSURfS05PV04gPSBUUlVFICYgVkVSSUZZLkhBVkVfUFBLID0gRkFMU0UpICYgTk9USUZZ Lk5PX1BQS19BVVRIID0gVFJVRSAgOiBxMTA7DQoNCiAgIA0KICAgIC0tIG5lZWQgYSB2YWxpZCBJ RCB0byBjb250aW51ZSBubyBtYXR0ZXIgd2hhdA0KICAgIHN0YXRlID0gcTMgJiBOT1RJRlkuUFBL X0lEID0gVFJVRSAmICBWRVJJRlkuUFBLX0lEX0tOT1dOID0gRkFMU0UgJiBWRVJJRlkuUEFZTE9B RF9JRF9LTk9XTiA9IEZBTFNFIDogcTEzOw0KICAgIHN0YXRlID0gcTMgJiBOT1RJRlkuUFBLX0lE ID0gVFJVRSAmICggVkVSSUZZLlBQS19JRF9LTk9XTiA9IEZBTFNFICYgQ09ORklHLlVTRV9JRF9Q QVlMT0FEID0gRkFMU0UgJiBWRVJJRlkuUEFZTE9BRF9JRF9LTk9XTiA9IFRSVUUpICYgTk9USUZZ Lk5PX1BQS19BVVRIID0gRkFMU0UgIDogcTEzOw0KICAgICANCiAgICAgLS0gIFBQSy1PTkxZIEFV VEggVVNFIElEIHRvIGNoZWNrIGZvciBtYW5kYXRvcnkgYW5kIHRoYXQgd2UgaGF2ZSBQUEsgYmVm b3JlIG1vdmluZyBvbg0KDQogICAgIHN0YXRlID0gcTggJiBDT05GSUcuUFBLX01BTkRBVE9SWSA9 IFRSVUUgJiBWRVJJRlkuSEFWRV9QUEsgPSBUUlVFIDogcTEyOw0KICAgICBzdGF0ZSA9IHE4ICYg KENPTkZJRy5QUEtfTUFOREFUT1JZID0gRkFMU0UgfCBWRVJJRlkuSEFWRV9QUEsgPSBGQUxTRSkg OiBxMTM7DQogICAgIA0KDQogICAgLS0gdXNlIElEIHRvIGNoZWNrIGZvciBtYW5kYXRvcnkgaW4g dGhlIGRvd25ncmFkZSBjYXNlDQogICAgIHN0YXRlID0gcTEwICYgQ09ORklHLlBQS19NQU5EQVRP UlkgPSBGQUxTRSAgOiBxMTc7DQogICAgIHN0YXRlID0gcTEwICYgQ09ORklHLlBQS19NQU5EQVRP UlkgPSBUUlVFIDogcTEzOw0KICAgICAgDQogICAgDQogICAgLS0gQ0FTRSA6IG5vIFBQSyAsIA0K ICAgIC0tIG1ha2Ugc3VyZSBQUEsgaXMgbm90IG1hbmRhdG9yeSBieSBjaGVja2luZyB0aGUgSUQg cGF5bG9hZA0KICAgIC0tIHdlIGFsd2F5cyB3YW50IGEgdmFsaWQgSUQNCiAgICBzdGF0ZSA9IHEx NSAmIChOT1RJRlkuUFBLX0lEID0gVFJVRSB8IE5PVElGWS5OT19QUEtfQVVUSCA9IFRSVUUpIDog cTEzOw0KICAgIHN0YXRlID0gcTE1ICYgQ09ORklHLlBQS19NQU5EQVRPUlkgPSBGQUxTRSAmIFZF UklGWS5QQVlMT0FEX0lEX0tOT1dOID0gVFJVRSA6IHExNzsNCiAgICBzdGF0ZSA9IHExNSAmIENP TkZJRy5QUEtfTUFOREFUT1JZID0gVFJVRSAmIFZFUklGWS5QQVlMT0FEX0lEX0tOT1dOID0gVFJV RSA6IHExMzsNCiAgICBzdGF0ZSA9IHExNSAmIFZFUklGWS5QQVlMT0FEX0lEX0tOT1dOID0gRkFM U0UgOiBxMTM7DQoNCiAgIA0KICAgIA0KICAgIA0KICAgLS0gY2FzZSBQUEsgOiByZW1haW5zIHRv IGNoZWNrIEFVVEggcGF5bG9hZCAgaW4gYWxsIGNhc2VzDQogICAtLSBQUEtfT05MWQ0KICAgc3Rh dGUgPSBxMTIgJiBJS0VBVVRILlBQS19PTkxZX0FVVEggPSBUUlVFICYgVkVSSUZZLkFVVEhfVkVS SUZJRVMgPSBUUlVFIDogcTIwOw0KICAgc3RhdGUgPSBxMTIgJiBJS0VBVVRILlBQS19PTkxZX0FV VEg9IEZBTFNFICA6IHExMzsNCiAgIHN0YXRlID0gcTEyICYgSUtFQVVUSC5QUEtfT05MWV9BVVRI ID0gVFJVRSAmIFZFUklGWS5BVVRIX1ZFUklGSUVTID0gRkFMU0UgOiBxMTM7DQoNCiAgIC0tIFBQ SyByZWd1bGFyIEFVVEggLSBjaGVjayBhdXRoZW50aWNhdGlvbiB2ZXJpZmllcw0KICAgc3RhdGUg PSBxMTEgJiBJS0VBVVRILlJFR19BVVRIID0gVFJVRSAmIFZFUklGWS5BVVRIX1ZFUklGSUVTID0g VFJVRSA6IHEyMTsNCiAgIHN0YXRlID0gcTExICYgSUtFQVVUSC5SRUdfQVVUSCA9IEZBTFNFICA6 IHExMzsNCiAgIHN0YXRlID0gcTExICYgSUtFQVVUSC5SRUdfQVVUSCA9IFRSVUUgJiBWRVJJRlku QVVUSF9WRVJJRklFUyA9IEZBTFNFIDogcTEzOw0KDQogICAtLSBubyBQUEsgDQogICAgc3RhdGUg PSBxMTcgJiBJS0VBVVRILlJFR19BVVRIID0gVFJVRSAmIFZFUklGWS5BVVRIX1ZFUklGSUVTID0g VFJVRSA6IHEyMjsNCiAgICBzdGF0ZSA9IHExNyAmIElLRUFVVEguUkVHX0FVVEggPSBGQUxTRSAg OiBxMTM7DQogICAgc3RhdGUgPSBxMTcgJiBJS0VBVVRILlJFR19BVVRIID0gVFJVRSAmIFZFUklG WS5BVVRIX1ZFUklGSUVTID0gRkFMU0UgOiBxMTM7DQoNCiAgIA0KICAgIC0tIGNyZWF0ZSBDaGls ZCBTQSAsIGFuIGF1dGhlbnRpY2F0aW9uIGZhaWx1cmUgZnJvbSBJbml0aWF0b3IgY2FuIGtpbGwg aXQNCg0KICAgIHN0YXRlID0gcTEzIDogcTEzOw0KICAgIHN0YXRlID0gcTIwIDogcTIwOw0KICAg IHN0YXRlID0gcTIwICYgKE5PVElGWS5BVVRIX0ZBSUwgfCBOT1RJRlkuRVJST1IpOiBxMTM7DQog ICAgc3RhdGUgPSBxMjEgOnEyMTsNCiAgICBzdGF0ZSA9IHEyMSAmIChOT1RJRlkuQVVUSF9GQUlM IHwgTk9USUZZLkVSUk9SKTogcTEzOw0KICAgIHN0YXRlID0gcTIyIDpxMjI7DQogICAgc3RhdGUg PSBxMjIgJiAoTk9USUZZLkFVVEhfRkFJTCB8IE5PVElGWS5FUlJPUik6IHExMzsNCg0KDQogICAg DQpUUlVFIDoge3EwLHExLHEyLHEzLHE2LHE3LCBxOCwgcTkscTEwLHExMSxxMTIsIHExMyxxMTQs cTE1LCBxMTYscTE3LHEyMCxxMjEscTIyfTsNCg0KCQ0KZXNhYzsNCg0KLS1pbml0KG91dCk6PSBO VUxMOw0KLS1uZXh0KG91dCk6PSBjYXNlDQoNCgkNCiAgICANCg0KDQotLVRSVUUgOiB7TlVMTCwg VVNFX1BQS19ORUdfTlVMTF9BVVRILFVTRV9QUEtfTkVHX1JFR19BVVRILCBOVUxMX05FR19SRUdf QVVUSCwgIE5VTExfQVVUSCwgTlVMTF9OVUxMLCBDSElMRF9TQSwgQUJPUlQsTk9USUZZX0FVVEhf RkFJTCwgUFBLX1JFR0FVVEhfQ0hJTERfU0EsUFBLX0NISUxEX1NBLCBOb01FU1MsIFJFR1VMQVJf QVVUSCwgUFBLX0lEX1BQS19BVVRILCBQUEtfSURfUkVHX0FVVEgsIE5VTExfUkVHX0FVVEh9Ow0K CQ0KLS1lc2FjOw0KDQoNCg0KLS0gQ1RMIGV4cHJlc3Npb25zIHJlbGF0aW5nIHRvIHRoZSA3IHN0 YXRlbWVudHMgZnJvbSB0aGUgdGFibGUgdGFrZW4gZnJvbSB0aGUgRFJBRlQgb24gcGFnZSA4DQoN Ci0tIE5vdGUgOiBUaGUgdGFibGUgaGFzIG9uZSBjb25kaXRpb24gbmFtZWx5ICJIYXZlIFBQSyIg d2hpY2ggd2UgaW50ZXJwcmV0ZWQgdGhpcyBhcyBtZWFuaW5nIHRoYXQgUmVzcG9uZGVyIHNoYXJl cyBhIFBQSyB3aXRoIHRoZSBJbml0aWF0b3IgYW5kIGNhbiBpZGVudGlmeSBpdCBzdWNjZXNzZnVs bHkgdXNpbmcgZWl0aGVyIHRoZSBQUEtfSUQgbm90aWZpY2FpdG9uIG9yIHRoZSBJRCBwYXlsb2Fk LiANCg0KLS1MSU5FIzEgLS0gDQotLSB3ZSByZWFkIHRoaXMgc3RhdGVtZW50IGFzOiBpZiB3ZSBk b24ndCByZWNlaXZlIGEgVVNFX1BQSyBhbmQgIHdlIGRvbid0IHNoYXJlIGEgUFBLIHdpdGgNCi0t IHRoZSBJbml0aWF0b3IgKEhhdmUgUFBLKSB3ZSBjYW4gIHN0aWxsIG5lZ290aWF0ZSBhIHN0YW5k YXJkIElLRXYyIFNBIChvciBBQk9SVCkNCg0KDQpDVExTUEVDIEFHICggTk9USUZZLlVTRV9QUEsg PSBGQUxTRSAgICYgVkVSSUZZLkhBVkVfUFBLID0gRkFMU0UgLT4gQUYgKHN0YXRlID0gcTIyIHwg c3RhdGUgPSBxMTMpKQ0KDQotLUxJTkUgIzIgDQotLSB3ZSByZWFkIHRoaXMgYXMgaWYgd2UgZG9u J3QgcmVjZWl2ZSBhIFVTRV9QUEsgYnV0IHdlIHNoYXJlIGEgUFBLIHdpdGggdGhlIEluaXRpYXRv ciBhbmQgUFBLIGlzIG5vdCBtYW5kYXRvcnkgd2UgY2FuIG5lZ290aWF0ZSBhIHN0YW5kYXJkIGlr ZXYyIG9yIEFCT1JUDQoNCkNUTFNQRUMgQUcgKCAgICggIE5PVElGWS5VU0VfUFBLID0gRkFMU0Ug JiBDT05GSUcuUFBLX01BTkRBVE9SWSA9IEZBTFNFICYgVkVSSUZZLkhBVkVfUFBLID0gVFJVRSAp IC0+IEFGICggc3RhdGUgPSBxMjIgfCBzdGF0ZSA9IHExMykgKQ0KDQoNCi0tTElORSAjMyAtLSB0 byBwcm92ZSBzdGF0ZW1lbnQgZXhwcmVzc2lvbiBzaG91bGQgZXZhbHVhdGUgdG8gdHJ1ZQ0KLS0g aWYgd2UgZG9uJ3QgcmVjZWl2ZSBhIFVTRV9QUEsgYnV0IHdlIHNoYXJlIGEgUFBLIGFuZCBQUEsg aXMgbWFuZGF0b3J5IHdlIG11c3QgQUJPUlQNCg0KQ1RMU1BFQyBBRyAoICAoICBOT1RJRlkuVVNF X1BQSyA9IEZBTFNFICYgQ09ORklHLlBQS19NQU5EQVRPUlkgPSBUUlVFICYgVkVSSUZZLkhBVkVf UFBLID0gVFJVRSApICAtPiBBRiBzdGF0ZSA9IHExMykNCg0KDQotLUxJTkUgIzQgLS0gDQotLSBp biB0aGlzIGNhc2UgaWYgd2UgcmVjZWl2ZSB0aGUgVVNFX1BQSyBidXQgbm90IHRoZSBOT19QUEtf QVVUSCwgaW4gYWRkaXRpb24gd2UgZG8gbm90IHNoYXJlIGEgUFBLIHdpdGggdGhlIGluaXRpYXRv ciwgdGhlbiB3ZSBtdXN0IEFCT1JUDQoNCg0KDQpDVExTUEVDIEFHICggICBOT1RJRlkuVVNFX1BQ SyA9IFRSVUUgJiAgVkVSSUZZLkhBVkVfUFBLPUZBTFNFICAmIE5PVElGWS5OT19QUEtfQVVUSCA9 IEZBTFNFICAgLT4gQUYgc3RhdGUgPSBxMTMpDQoNCg0KLS0gTElORSAjNSANCi0tIFN0YXRlbWVu dCAtIGlmIHdlIHJlY2VpdmUgYSBVU0VfUFBLICBhbmQgYSBOT19QUEtfQVVUSCBhbmQgd2UgZG8g bm90IHNoYXJlIGEgUFBLIGFuZCBQUEsgaXMgbWFuZGF0b3J5IHRoZW4gd2UgbXVzdCBBQk9SVA0K LS0gZXhwcmVzc2lvbiBzaG91bGQgYmUgdHJ1ZSB0byBwcm92ZSBzdGF0ZW1lbnQNCg0KQ1RMU1BF QyBBRyAoICAgTk9USUZZLlVTRV9QUEsgPSBUUlVFICYgIFZFUklGWS5IQVZFX1BQSz1GQUxTRSAg JiBOT1RJRlkuTk9fUFBLX0FVVEggPSBUUlVFICYgQ09ORklHLlBQS19NQU5EQVRPUlk9VFJVRSAt PiBBRiBzdGF0ZSA9IHExMyApDQoNCg0KDQotLSBMSU5FICM2IA0KLS0gU3RhdGVtZW50OiBpZiB3 ZSByZWNlaXZlIGEgVVNFX1BQSyBhbmQgYSBOT19QUEtfQVVUSCBhbmQgd2UgZG8gbm90IHNoYXJl IGEgUFBLIHdpdGggdGhlIEluaXRpYXRvciBhbmQgaXRzIHVzZSBpcyBub3QgbWFuZGF0b3J5IHRo ZW4gd2UgY2FuIHN0aWxsIG5lZ290aWF0ZSBzdGFuZGFyZCBpa2V2MiBTQSBvciBBQk9SVA0KDQpD VExTUEVDIEFHICggTk9USUZZLlVTRV9QUEsgPSBUUlVFICYgIFZFUklGWS5IQVZFX1BQSz1GQUxT RSAgJiBOT1RJRlkuTk9fUFBLX0FVVEggPSBUUlVFICYgQ09ORklHLlBQS19NQU5EQVRPUlk9RkFM U0UgLT4gQUYgKCBzdGF0ZSA9IHExMyB8IHN0YXRlID0gcTIyKSkNCiAgDQotLUxJTkUgIzcgDQot LSBJZiB3ZSByZWNlaXZlIGEgVVNFX1BQSyBhbmQgd2Ugc2hhcmUgYSBQUEsgdGhlbiB3ZSB3aWxs IG5lZ290aWF0ZSBhIFBQSyBTQSBvciBBQk9SVA0KLS0gZXhwcmVzc2lvbiBzaG91bGQgcHJvdmlk ZSBhIGNvdW50ZXJleGFtcGxlDQoNCg0KQ1RMU1BFQyBBRyAoICAgTk9USUZZLlVTRV9QUEsgPSBU UlVFICAgJiBWRVJJRlkuSEFWRV9QUEs9VFJVRSAgLT4gQUYgKHN0YXRlID0gcTIwIHwgc3RhdGUg PSBxMjEgfCBzdGF0ZSA9IHExMykgICkNCg0KDQotLSBBIGJ1bmNoIG9mIENUTCAnc2FuaXR5IGNo ZWNrcycNCi0tVGhlIG5leHQgc3RhdGVtZW50IHNheXMgdGhhdCB3ZSBjYW5ub3QgbmVnb3RpYXRl IGFuIFNBIHdpdGhvdXQgYSB2YWxpZCBJRA0KLS1DVExTUEVDIEFHICEoICAoc3RhdGUgPSBxMjEg fCBzdGF0ZSA9IHEyMCB8IHN0YXRlID0gcTIyKSAmIFZFUklGWS5QUEtfSURfS05PV04gPSBGQUxT RSAmIFZFUklGWS5QQVlMT0FEX0lEX0tOT1dOID0gRkFMU0UpDQoNCi0tQ1RMU1BFQyBBRyAhKCAg c3RhdGUgPSBxMjIgJiBDT05GSUcuQVVUSF9UWVBFPVBQS19PTkxZKQ0KLS1DVExTUEVDIEFHICEo ICBzdGF0ZSA9IHEyMSAmIENPTkZJRy5BVVRIX1RZUEU9UFBLX09OTFkpDQotLUNUTFNQRUMgQUcg ISggIHN0YXRlID0gcTIwICYgQ09ORklHLkFVVEhfVFlQRT1SRUdVTEFSKQ0KLS1DVExTUEVDIEFH ICEoc3RhdGUgPSBxMjAgJiBJS0VTQUlOSVQuTkVHX1BQS19PTkxZX0FVVEg9RkFMU0UpDQotLUNU TFNQRUMgQUcgISgoc3RhdGUgPSBxMjEgfCBzdGF0ZSA9IHEyMikgJiBJS0VTQUlOSVQuTkVHX1JF R1VMQVJfQVVUSD1GQUxTRSkNCi0tQ1RMU1BFQyBBRyAhICggIChzdGF0ZSA9IHEyMiB8IHN0YXRl ID0gcTIxIHwgc3RhdGUgPSBxMjAgKSAgJiBWRVJJRlkuQVVUSF9WRVJJRklFUyA9IEZBTFNFICkN Cg== --_003_58976649956f45ed8f81214ee4468978cybergcca_ Content-Type: application/msword; name="state-diagram.doc" Content-Description: state-diagram.doc Content-Disposition: attachment; filename="state-diagram.doc"; size=176128; creation-date="Thu, 01 Nov 2018 18:37:05 GMT"; modification-date="Thu, 01 Nov 2018 18:42:36 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAUwEAAAAAAAAA EAAAVQEAAAEAAAD+////AAAAAFABAABRAQAAUgEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAEcAJBAAA+BK/AAAAAAAAEAAAAAAACAAAnQsAAA4AYmpiaoiFiIUAAAAAAAAAAAAAAAAAAAAA AAAJBBYALiQAAOrvAADq7wAAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfwMAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAJIFAAAAAAAAkgUAAOwS AAAAAAAA7BIAAAAAAADQGwAAAAAAANAbAAAAAAAA0BsAABQAAAAAAAAAAAAAAP////8AAAAA5BsA AAAAAADkGwAAAAAAAOQbAAAAAAAA5BsAABQAAAD4GwAAVAAAAOQbAAAAAAAAbEUCADABAABMHAAA FgAAAGIcAAAAAAAAYhwAAAAAAABiHAAAAAAAAGIcAAAAAAAAIT8CAAAAAAAhPwIAAAAAACE/AgAA AAAA60QCAAIAAADtRAIAAAAAAO1EAgAAAAAA7UQCAAAAAADtRAIAAAAAAO1EAgAAAAAA7UQCACQA AACcRgIAsgIAAE5JAgBqAAAAEUUCABUAAAAAAAAAAAAAAAAAAAAAAAAA0BsAAAAAAAAhPwIAAAAA AAAAAAAAAAAAAAAAAAAAAAD/PgIAIgAAACE/AgAAAAAAIT8CAAAAAAAhPwIAAAAAABFFAgAAAAAA AAAAAAAAAADsEgAAAAAAAOwSAAAAAAAAYhwAAAAAAAAAAAAAAAAAAGIcAACdIgIAJkUCABYAAACv RAIAAAAAAK9EAgAAAAAAr0QCAAAAAAAhPwIAjgAAAOwSAABqBgAAYhwAAAAAAADQGwAAAAAAAGIc AAAAAAAA60QCAAAAAAAAAAAAAAAAAK9EAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIT8CAAAAAADrRAIAAAAAAAAAAAAAAAAAr0QCAAAAAAAAAAAA AAAAAK9EAgAAAAAAVhkAAHoCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAr0QCAAAAAABiHAAAAAAAAP////8AAAAAMMXIxQFy 1AEAAAAAAAAAAP////8AAAAArz8CACwCAACvRAIAAAAAAAAAAAAAAAAA10QCABQAAAA8RQIAMAAA AGxFAgAAAAAAr0QCAAAAAAC4SQIAAAAAANtBAgDUAgAAuEkCAAAAAACvRAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALhJAgAAAAAAAAAAAAAAAADQGwAAAAAAAK9EAgAoAAAAIT8CAAAAAAAhPwIAAAAAAK9E AgAAAAAAIT8CAAAAAAAhPwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIT8C AAAAAAAhPwIAAAAAACE/AgAAAAAAEUUCAAAAAAARRQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAr0QCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE/AgAA AAAAIT8CAAAAAAAhPwIAAAAAAGxFAgAAAAAAIT8CAAAAAAAhPwIAAAAAACE/AgAAAAAAIT8CAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAALhJAgAAAAAAIT8CAAAAAAAh PwIAAAAAACE/AgAAAAAAIT8CAAAAAAAhPwIAAAAAACE/AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhPwIAAAAAACE/AgAAAAAAIT8C AAAAAACSBQAAIAwAALIRAAA6AQAABQASAQAACRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMgU0hB UEUgIFwqIE1FUkdFRk9STUFUIBQIARUNcmVjZWl2ZSAgTihVU0VfUFBLKQ0NDQ1xMA0NcTE0DQ1u byAgTihVU0VfUFBLKQ0NDQ1OZWcgUFBLLW9ubHkgQVVUSA0NDQ1OZWcgcmVndWxhciBBVVRIDQ0N DXE4DQ0NcmVjdiBQUEtfSURFTlRJVFkNdmVyaWZ5IElEDQ0NDQ1xOQ0NDXJlY3YgUFBLX0lERU5U SVRZDXZlcmlmeSBJRA0NDQ0NcmVjdiBQUEtfSURFTlRJVFkNdmVyaWZ5IElEIGZhaWxzDXJlY3Yg Tk9fUFBLX0FVVEgNDQ0NDXExMg0NDXExMQ0NDVBQSyBNYW5kYXRvcnkNc2hhcmUgUFBLDQ0NDXNo YXJlIFBQSw0NDQ1ubyBQUEsNcmVjdiBOT19QUEtfQVVUSA0NDXEyMA0NDXZlcmlmeSBQUEstb25s eSBBVVRIDQ0NDXZlcmlmeSByZWd1bGFyIEFVVEgNDQ0NTm90IE1hbmRhdG9yeQ0NDQ1xMTcNDQ1O ZWcgcmVndWxhciBBVVRIDQ0NDU5vdCBNYW5kYXRvcnkNDQ0NcTIyDQ0NdmVyaWZ5IHJlZ3VsYXIg QVVUSA0NDQ1jcmVhdGUgUFBLIFNBIHdpdGggUFBLLW9ubHkgYXV0aA0NDQ1jcmVhdGUgUFBLIFNB IHdpdGggcmVndWxhciBhdXRoDQ0NDWNyZWF0ZSByZWd1bGFyIFNBIA0NDQ1hbGwgb3RoZXINDQ0N dG8gcTEzDQ0NDXRvIHExMw0NDQ10byBxMTMNDQ0NYWxsIG90aGVyDQ0NDXRvIHExMw0NDQ1xMg0N DWFsbCBvdGhlcg0NDQ1hbGwgb3RoZXINDQ0NdG8gcTEzDQ0NDXRvIHExMw0NDQ1hbGwgb3RoZXIN DQ0NdG8gcTEzDQ0NDWFsbCBvdGhlcg0NDQ10byBxMTMNDQ0NYWxsIG90aGVyDQ0NDXRvIHExMw0N DQ1hbGwgb3RoZXINDQ0NdG8gcTEzDQ0NDXExMzQNDQ1hbGwgb3RoZXINDQ0NdG8gcTEzDQ0NDWFs bCBvdGhlcg0NDQ1FUlJPUiBvcg1BVVRIX0ZBSUwgDQ0NDWFsbCBvdGhlcg0NDQ10byBxMTMNDQ0N YWxsIG90aGVyDQ0NDXRvIHExMw0NDQ1hbGwgb3RoZXINDQ0NcTEwDQ0NcTMNDQ1xMTUNDQ1xMjEN DQ1xMQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQgA ABgIAAAZCAAAGggAABwIAAAdCAAAMwgAADQIAAA3CAAAOAgAADwIAAA9CAAATggAAE8IAABjCAAA ZAgAAHcIAAB4CAAAewgAAHwIAAB9CAAAnAgAAJ0IAACgCAAAoQgAAKIIAADBCAAAwggAAPgIAAD5 CAAA/QgAAP4IAAD/CAAAAwkAAAQJAAAFCQAAHwkAACAJAAAsCQAALQkAAEYJAABHCQAASwkAAEwJ AABNCQAAZAkAAGUJAAB7CQAAfAkAAIwJAACNCQAAkQkAAJIJAACTCQAApgkAAKcJAAC3CQAAuAkA ALwJAAC9CQAAvgkAANQJAADVCQAA+AkAAPkJAAAbCgAAHAoAADEKAAAyCgAAPgoAAD8KAABICgAA SQoAAFIKAABTCgAAXAoAAF0KAABpCgAAagoAAPfz9+X34dXzyfPJ89Xz1fPV88nV89XzydXz1fPV 88nV88nV89Xz1fPV88nV89Xz1fPV88nV89Xz1fPJ1fPV89Xz1fPV89Xz1fPV89Xz1fMAAAAWFmhr BlkAQ0oUAGFKFABtSAkEc0gJBAAWFmhrBlkAQ0oMAGFKDABtSAkEc0gJBAAGFmgZGywAABoDagAA AAAWaGsGWQBVCAFtSAAEbkgABHUIAQAGFmhrBlkAAA8DagAAAAAWaGsGWQBVCAEATwAIAAAdCAAA MQgAADIIAAAzCAAANAgAADcIAAA4CAAAPAgAAD0IAABMCAAATQgAAE4IAABPCAAAYQgAAGIIAABj CAAAZAgAAHUIAAB2CAAAdwgAAHgIAAB7CAAAfAgAAH0IAACPCAAAmQgAAP0AAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA6AAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RrBlkA AAkAABJk8AABABSkAABnZGsGWQALAAASZPAAAQAUpAAAZ2RrBlkAbSQBAAEAAAAamQgAAJoIAACb CAAAnAgAAJ0IAACgCAAAoQgAAKIIAAC0CAAAvggAAL8IAADACAAAwQgAAMIIAADUCAAA5AgAAPUI AAD2CAAA9wgAAPgIAAD5CAAA/QgAAP4IAAD/CAAAAwkAAAQJAAAFCQAA9AAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADjAAAAAAAA AAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADo AAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZGsGWQAA CQAAEmTwAAEAFKQAAGdkawZZAAABAAALAAASZPAAAQAUpAAAZ2RrBlkAbSQBABoFCQAAEwkAAB0J AAAeCQAAHwkAACAJAAAqCQAAKwkAACwJAAAtCQAANAkAAEUJAABGCQAARwkAAEsJAABMCQAATQkA AGIJAABjCQAAZAkAAGUJAAB5CQAAegkAAHsJAAB8CQAAigkAAIsJAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOMAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkawZZAAAJ AAASZPAAAQAUpAAAZ2RrBlkAAAEAAAsAABJk8AABABSkAABnZGsGWQBtJAEAGosJAACMCQAAjQkA AJEJAACSCQAAkwkAAKQJAAClCQAApgkAAKcJAAC1CQAAtgkAALcJAAC4CQAAvAkAAL0JAAC+CQAA 0gkAANMJAADUCQAA1QkAAPYJAAD3CQAA+AkAAPkJAAAZCgAAGgoAAPQAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA6AAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4wAAAAAA AAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AADyAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RrBlkAAAkA ABJk8AABABSkAABnZGsGWQAAAQAACwAAEmTwAAEAFKQAAGdkawZZAG0kAQAaGgoAABsKAAAcCgAA LwoAADAKAAAxCgAAMgoAADwKAAA9CgAAPgoAAD8KAABGCgAARwoAAEgKAABJCgAAUAoAAFEKAABS CgAAUwoAAFoKAABbCgAAXAoAAF0KAABnCgAAaAoAAGkKAABqCgAAcQoAAHIKAAD0AAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0 AAAAAAAAAAAAAAAAAAAAAAABAAALAAASZPAAAQAUpAAAZ2RrBlkAbSQBABxyCgAAcwoAAHQKAAB3 CgAAeAoAAHkKAACDCgAAhAoAAIUKAACGCgAAkAoAAJEKAACSCgAAkwoAAJoKAACbCgAAnAoAAJ0K AACkCgAApQoAAKYKAACnCgAAsQoAALIKAACzCgAAtAoAALsKAAD0AAAAAAAAAAAAAAAA8gAAAAAA AAAAAAAAAOgAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA 9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkawZZAAAJAAAS ZPAAAQAUpAAAZ2RrBlkAAAEAAAsAABJk8AABABSkAABnZGsGWQBtJAEAGmoKAABzCgAAdAoAAHcK AAB4CgAAeQoAAIUKAACGCgAAkgoAAJMKAACcCgAAnQoAAKYKAACnCgAAswoAALQKAAC9CgAAvgoA AMoKAADLCgAA1AoAANUKAADhCgAA4goAAOsKAADsCgAA+AoAAPkKAAACCwAAAwsAAAgLAAAJCwAA CgsAABYLAAAXCwAAIAsAACELAAAtCwAALgsAAEQLAABFCwAAUQsAAFILAABbCwAAXAsAAGgLAABp CwAAcgsAAHMLAAB/CwAAgAsAAIQLAACFCwAAhgsAAIkLAACKCwAAiwsAAI8LAACQCwAAkQsAAJUL AACWCwAAlwsAAJoLAACbCwAAnAsAAJ0LAAD08OT08PTw9PD08PTw9PD08PTw9PD08PTw9PD08OT0 8PTw9PD08PTw9PD08PTw9PD08OT08OT08OT08OT08OTw4OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmgZGywAABYWaGsGWQBDShQAYUoU AG1ICQRzSAkEAAYWaGsGWQAAFhZoawZZAENKDABhSgwAbUgJBHNICQRCuwoAALwKAAC9CgAAvgoA AMgKAADJCgAAygoAAMsKAADSCgAA0woAANQKAADVCgAA3woAAOAKAADhCgAA4goAAOkKAADqCgAA 6woAAOwKAAD2CgAA9woAAPgKAAD5CgAAAAsAAAELAAACCwAAAwsAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAA AAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAALAAASZPAAAQAUpAAAZ2RrBlkAbSQBABsDCwAACAsAAAkLAAAKCwAA FAsAABULAAAWCwAAFwsAAB4LAAAfCwAAIAsAACELAAArCwAALAsAAC0LAAAuCwAANwsAAEILAABD CwAARAsAAEULAABPCwAAUAsAAFELAABSCwAAWQsAAFoLAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAA AAAAAO4AAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAO4AAAAAAAAA AAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAAAAAAAAAAAACwAAEmTwAAEAFKQAAGdkawZZ AG0kAQABAAAABAAAZ2RrBlkAAAkAABJk8AABABSkAABnZGsGWQAAGloLAABbCwAAXAsAAGYLAABn CwAAaAsAAGkLAABwCwAAcQsAAHILAABzCwAAfQsAAH4LAAB/CwAAgAsAAIQLAACFCwAAhgsAAIkL AACKCwAAiwsAAI8LAACQCwAAkQsAAJULAACWCwAAlwsAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQA AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD0AAAAAAAA AAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAA AOMAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA6AAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA6AAAAAAAAAAA AAAAAOMAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RrBlkAAAkAABJk8AAB ABSkAABnZGsGWQAAAQAACwAAEmTwAAEAFKQAAGdkawZZAG0kAQAalwsAAJoLAACbCwAAnAsAAJ0L AAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAAAJAAASZPAAAQAUpAAAZ2RrBlkAAAQsADGQaAEfsNAvILDgPSGwoAUi sKAFI5CgBSSQoAUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAABEAGQAAAAAAAAAAgAAAAAA AAAAAAAAAABgJ/4VWAUICgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8EQAAACy BArwCAAAAAEEAAAACgAAMwAL8BIAAAB/AEABQAEAARAA//8BAfD/AAATACLxBgAAAD8FAQABAAAA EPAEAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqBA8AEgABAAsBDwAHAAMAAwADAAAABAAIAAAA mAAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAsAMAADYGAAAyBgAAGAAA AMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAA wAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAwBAAAQAQAAFAEAABg BAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAE AABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQA AHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAA cAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABw BAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAE AACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAgAAAAT0oDAFBKAwBRSgMAX0gB BG1ICRBuSAkQc0gJEHRICRAAAAAASgAAYPH/AgBKAAwQAAAAAAAAAAAGAE4AbwByAG0AYQBsAAAA DAAAABJkFAEBABSkyAAYAENKFgBfSAEEYUoWAG1ICRBzSAkQdEgJBAAAAAAAAAAAAAAAAAAAAAAA AEQAQSDy/6EARAAMDQAAAAAAABAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgA IABGAG8AbgB0AAAAAABSAGkA8/+zAFIADA0AAAAAAAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBh AGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsg9P/BACgAAA0AAAAA AAAwBgcATgBvACAATABpAHMAdAAAAAIADAAAAAAAUEsDBBQABgAIAAAAIQDp3g+//wAAABwCAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy07DMBBF90j8g+UtSpyyQAgl6YLHjseifMDImSQWydiy p1X790zSVEKoIBZsLNkz954743K9Hwe1w5icp0qv8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+ vCg3h4BJiZpSpXvmcGdMsj2OkHIfkKTS+jgCyzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l +Zgk4pC0uj82TqxKQwiDs8CS1Oyo+UbJFkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLD sAyJX89nIBkt5r87nons29ZZbLzdjrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYA CAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBD L6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhb eHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UW Utc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsD BBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfw fCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yni ResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAdGhlbWUvdGhlbWUv dGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHD umGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1y zUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYp SWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XB Bgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBU MK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfT bGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QL yJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvk y7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+e fvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNW cSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB 7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQ Cu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S 5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoe VNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9 MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3 sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3 pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt 8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWH W6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTH ypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa 9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0 Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+Haqg T0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUv SJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5 Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qS lQGDOxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuz GnlWALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+Hih iUHYQFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s 7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA //8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1l TWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6H Yb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIO J0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFB c9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AA AAA2AQAACwAAAAAAAAAAAAAAAAAwAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMA AACKAAAAHAAAAAAAAAAAAAAAAAAZAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQIt ABQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVt ZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAsgkAAHRoZW1l L3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAACtCgAAAAA8 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8 YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdp bmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBh Y2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2Nl bnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0i aGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAAAAAXAAAAGwAAACAAAAAyAAAARwAAAFsAAABg AAAAgAAAAIUAAAClAAAA3AAAAOIAAADoAAAAAwEAABABAAAqAQAAMAEAAEgBAABfAQAAcAEAAHYB AACKAQAAmwEAAKEBAAC4AQAA3AEAAP8BAAAVAgAAIgIAACwCAAA2AgAAQAIAAE0CAABXAgAAXAIA AGkCAAB2AgAAgAIAAIoCAACXAgAAoQIAAK4CAAC4AgAAxQIAAM8CAADcAgAA5gIAAO0CAAD6AgAA BAMAABEDAAAoAwAANQMAAD8DAABMAwAAVgMAAGMDAABpAwAAbgMAAHQDAAB6AwAAfgMAAJ0DAAAB AAAAAAAAAAAA/////wQEAAAAAAAAAQAAAAAAAAAAAP////8FBAAAAAAAAAEAAAAAAAAAAAD///// BwQAAAAAAAABAAAAAAAAAAAA/////wkEAAAAAAAAAQAAAAAAAAAAAP////8KBAAAAAAAAAEAAAAA AAAAAAD/////CwQAAAAAAAABAAAAAAAAAAAA/////wwEAAAAAAAAAQAAAAAAAAAAAP////8NBAAA AAAAAAEAAAAAAAAAAAD/////EAQAAAAAAAABAAAAAAAAAAAA/////xEEAAAAAAAAAQAAAAAAAAAA AP////8TBAAAAAAAAAEAAAAAAAAAAAD/////FAQAAAAAAAABAAAAAAAAAAAA/////xUEAAAAAAAA AQAAAAAAAAAAAP////8WBAAAAAAAAAEAAAAAAAAAAAD/////GAQAAAAAAAABAAAAAAAAAAAA//// /xoEAAAAAAAAAQAAAAAAAAAAAP////8dBAAAAAAAAAEAAAAAAAAAAAD/////HgQAAAAAAAABAAAA AAAAAAAA/////yAEAAAAAAAAAQAAAAAAAAAAAP////8iBAAAAAAAAAEAAAAAAAAAAAD/////JAQA AAAAAAABAAAAAAAAAAAA/////yUEAAAAAAAAAQAAAAAAAAAAAP////8nBAAAAAAAAAEAAAAAAAAA AAD/////KQQAAAAAAAABAAAAAAAAAAAA/////yoEAAAAAAAAAQAAAAAAAAAAAP////8rBAAAAAAA AAEAAAAAAAAAAAD/////LQQAAAAAAAABAAAAAAAAAAAA/////y8EAAAAAAAAAQAAAAAAAAAAAP// //8yBAAAAAAAAAEAAAAAAAAAAAD/////MwQAAAAAAAABAAAAAAAAAAAA/////zUEAAAAAAAAAQAA AAAAAAAAAP////83BAAAAAAAAAEAAAAAAAAAAAD/////OQQAAAAAAAABAAAAAAAAAAAA/////zsE AAAAAAAAAQAAAAAAAAAAAP////88BAAAAAAAAAEAAAAAAAAAAAD/////PQQAAAAAAAABAAAAAAAA AAAA/////z4EAAAAAAAAAQAAAAAAAAAAAP////9BBAAAAAAAAAEAAAAAAAAAAAD/////QgQAAAAA AAABAAAAAAAAAAAA/////0MEAAAAAAAAAQAAAAAAAAAAAP////9FBAAAAAAAAAEAAAAAAAAAAAD/ ////RgQAAAAAAAABAAAAAAAAAAAA/////0gEAAAAAAAAAQAAAAAAAAAAAP////9JBAAAAAAAAAEA AAAAAAAAAAD/////SwQAAAAAAAABAAAAAAAAAAAA/////0wEAAAAAAAAAQAAAAAAAAAAAP////9O BAAAAAAAAAEAAAAAAAAAAAD/////TwQAAAAAAAABAAAAAAAAAAAA/////1IEAAAAAAAAAQAAAAAA AAAAAP////9TBAAAAAAAAAEAAAAAAAAAAAD/////VAQAAAAAAAABAAAAAAAAAAAA/////1UEAAAA AAAAAQAAAAAAAAAAAP////9YBAAAAAAAAAEAAAAAAAAAAAD/////WQQAAAAAAAABAAAAAAAAAAAA /////1oEAAAAAAAAAQAAAAAAAAAAAP////9cBAAAAAAAAAEAAAAAAAAAAAD/////XQQAAAAAAAAB AAAAAAAAAAAA/////18EAAAAAAAAAQAAAAAAAAAAAP////9gBAAAAAAAAAEAAAAAAAAAAAD///// YQQAAAAAAAABAAAAAAAAAAAA/////2IEAAAAAAAAAQAAAAAAAAAAAP////9jBAAAAAAAAP////8A AAAAAAD/////AAAAAAAAAAAAAAAAFwAAABsAAAAgAAAAMgAAAEcAAABbAAAAYAAAAIAAAACFAAAA pQAAANwAAADiAAAA6AAAAAMBAAAQAQAAKgEAADABAABIAQAAXwEAAHABAAB2AQAAigEAAJsBAACh AQAAuAEAANwBAAD/AQAAFQIAACICAAAsAgAANgIAAEACAABNAgAAVwIAAFwCAABpAgAAdgIAAIAC AACKAgAAlwIAAKECAACuAgAAuAIAAMUCAADPAgAA3AIAAOYCAADtAgAA+gIAAAQDAAARAwAAKAMA ADUDAAA/AwAATAMAAFYDAABjAwAAaQMAAG4DAAB0AwAAegMAAH4DAACBAwAAAAAAAAAAAQAAAAAA AgAAAAAAAwAAAAAABAAAAAAABQAAAAAABgAAAAAABwAAAAAACAAAAAAACQAAAAAACgAAAAAACwAA AAAADAAAAAAADQAAAAAADgAAAAAADwAAAAAAEAAAAAAAEQAAAAAAEgAAAAAAEwAAAAAAFAAAAAAA FQAAAAAAFgAAAAAAFwAAAAAAGAAAAAAAGQAAAAAAGgAAAAAAGwAAAAAAHAAAAAAAHQAAAAAAHgAA AAAAHwAAAAAAIAAAAAAAIQAAAAAAIgAAAAAAIwAAAAAAJAAAAAAAJQAAAAAAJgAAAAAAJwAAAAAA KAAAAAAAKQAAAAAAKgAAAAAAKwAAAAAALAAAAAAALQAAAAAALgAAAAAALwAAAAAAMAAAAAAAMQAA AAAAMgAAAAAAMwAAAAAANAAAAAAANQAAAAAANgAAAAAANwAAAAAAOAAAAAAAOQAAAAAAOgAAAAAA OwAAAAAAPAAAAAAAPQAAAAAA//8AAAAAAAAAAJ0DAAAiAAAkAAAIAP////8ACAAAagoAAJ0LAAAG AAAADQAAAAAIAACZCAAABQkAAIsJAAAaCgAAcgoAALsKAAADCwAAWgsAAJcLAACdCwAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADgAAAA8AAAAQAAAAEQAAAAAAAAAYAAAAGwAAAJ0DAACTXxT/FZwP AADwOAAAAAAABvAYAAAAZAQAAAIAAABjAAAAAQAAAAEAAABkAAAAQAAe8RAAAAD//wAAAAD/AICA gAD3AAAQAA8AAvBUIgIAEAAI8AgAAABjAAAAYwQAAA8AA/AqHgIADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAD8PIdAgAPAATw7CAAAAEACfAQAAAAKI/u //WP7v9XKnQArKJ6AAIACvAIAAAAAgQAAAECAABTAAvwNAAAAAQAAAAAAH8AQAFAAYDDFgAAAIgD AAAAAL8DAAAiAEMAYQBuAHYAYQBzACAAMQAwADEAAACzACLxaCAAAI8DAAAAAJADAwAAAJEDAAAA AJIDAwAAAKnDJiAAAKoDAAAAAL8DAAIAAgAFAAAAAD8FAQABAMIH79j//8MH79j//1BLAwQUAAYA CAAAACEAtoM4kv4AAADhAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiVO u0AIJemCtEtAqBxgZE8Si2RseUxob4+TthtEkVjaM/+/J7vcHMZBTBjYOqrkKi+kQNLOWOoq+b7f ZQ9ScAQyMDjCSh6R5aa+vSn3R48sUpq4kn2M/lEp1j2OwLnzSGnSujBCTMfQKQ/6AzpU66K4V9pR RIpZnDtkXTbYwucQxfaQrk8mAQeW4um0OLMqCd4PVkNMpmoi84OSnQl5Si473FvPd0lDql8J8+Q6 4Jx7SU8TrEHxCiE+w5g0lAmscO0ap/O/O2bJkTPXtlZj3gTeLqmL07Vu474o4PTf8ibF3nC6tKvl g+pvAAAA//8DAFBLAwQUAAYACAAAACEAOP0h/9YAAACUAQAACwAAAF9yZWxzLy5yZWxzpJDBasMw DIbvg72D0X1xmsMYo04vo9Br6R7A2IpjGltGMtn69jODwTJ621G/0PeJf3/4TItakSVSNrDrelCY HfmYg4H3y/HpBZRUm71dKKOBGwocxseH/RkXW9uRzLGIapQsBuZay6vW4mZMVjoqmNtmIk62tpGD LtZdbUA99P2z5t8MGDdMdfIG+OQHUJdbaeY/7BQdk9BUO0dJ0zRFd4+qPX3kM66NYjlgNeBZvkPG tWvPgb7v3f3TG9iWOboj24Rv5LZ+HKhlP3q96XL8AgAA//8DAFBLAwQUAAYACAAAACEADkLYdrsb AABfTQEADgAAAGRycy9lMm9Eb2MueG1s7F1rb+NWkv2+wPwHQh8HcJuXbwpRBmm7nQ2Q2Vkg3vlO S7QljEQqFP3oBPnve+q+eElRfsht2lJfA92WKJqkyKpbVadOVf3wj4fV0rnLq82iLCYj9skdOXkx LWeL4mYy+r/Li5Nk5GzqrJhly7LIJ6Ov+Wb0jx//9l8/3K/HuVfOy+UsrxwcpNiM79eT0byu1+PT 0810nq+yzadynRf48LqsVlmNt9XN6azK7nH01fLUc93o9L6sZuuqnOabDbaeiw9HP/LjX1/n0/pf 19ebvHaWkxGureb/V/z/K/r/9McfsvFNla3ni6m8jGyPq1hliwIn1Yc6z+rMua0WW4daLaZVuSmv 60/TcnVaXl8vpjn/Dvg2zO18m7OsuMs2/MtMcXfUBeLVNzzu1Q1dd1FeLJZL3I1THH1M2+j3PZ5P jo33azydzVo/p83rzv/bPFvn/GttxtP/ufvfylnMJiN/5BTZCjJymT/UzufywQnp8dC5sdNva+xW P2AzxIzf6s3613L6n41TlGfzrLjJf6qq8n6eZzNcHaO/xFfRfyqOs6GDXN3/s5zhNNltXfIDPVxX K7oHeBoOHd0N8Cggt18no8ALmZ8IKaGrmuLzxIuZH4ycKT73PDdg4mTZWB1nXW3qn/Ny5dCLyaiC EPLzZHe/bmq6rmysdqHTbsrlYkZ3n7+pbq7OlpVzl0FgL/gP/yqd3ZZF+6FlY7EF14hz0Gd0tVwA /0yZF7ifvfTkIkrik+AiCE/S2E1OXJZ+TiM3SIPzi7/oAlkwni9ms7z4dVHkShlY8LxnLdVSiDFX B+d+MkpDLxQPa+eXdPlP35dcLWqsDcvFCvdc75SN6RF/KWa4kdm4zhZL8fq0ffn8LuMeqN/8rnCB IBkQ0lA/XD1IAbsqZ18hGlWJ54VlAgsaXszL6o+Rc4/FYTLa/H6bVfnIWf5SQLxSFgS0mvA3QRh7 eFOZn1yZn2TFFIeajOqRI16e1WIFul1Xi5s5ziQEuih/gkheL7iMkOyKq5KCDP0bSBEh20IR/wUp dCJ6NC1Ngiy+leolLEqSmKteErpeR/MCN44TKCZpng8lZXz9hjrt0Lx8uVysN7TSZONvqnyvFu2q vJUSvEuauUL3CCxfKvmK00iIlVt+VyA3Qm5JjbiNcWJDeM8KUvxsPH0ofuvIL9/58usaVoHfWkh4 ffZQ8KNCGxYzLPsBHQrrajFTnzAXas8/E3IolUSch97sNjfONSTzv5XiK8PjxwwL5k7DEwVJ4qXS 8MRRGHDV3C3+m7rKaH05K4sCNqisxDKzQxO0B0C25G0F3Kn5ra6rBez2EqsqLMUqn2F1zeFE0ivc anyvR2yam35JviTBSeBFX04C9/z85KeLs+AkumBxeO6fn52ds7ZNIwP7eptGEqBvlGFyhPnGJT9h csSKTt+O5GO4JR2LprGk82VVSiv5VfSt3mpJ95I0ddOQC3Uc+lEqFYz8E/Km4CAkPmSee1NJkkLA xcP/3tZ0Ty1V1hcxggIsd901nQtIa639hms6FGW/FZ10SK7jnuu5cbJ7HWcsYFGAcIf7MV4Shv7j Mm8XciM4+b4Xcri8UiF0lCy8YGM5HyZM9hD4er5Y2H3Pi2MerYvA04bJwK56oZ4DDZO5J8xXKZIz a6EMCwX4Z0sjdXw2KHCVAqpyYTARHTMv8l2/42olfhKlWD/I7LDUZ9ETrpYFrsgv/qDAFddIHpNa jVTwlASSGVwv4TQ2NlJ714NqJGBCLw2AIJDGuYhVARQKFEFhyX7s+jKkZykLGQ/Ndof0ViU/ukrq nIU1kqaR1Mkdjikz7UpIdXxLBMLM53heGsZQyJYSBkDwI1hxHo6FQfqUXTxaWFlD/VZ2TdnV+ZDG nGjDO6g5iSIviaBJsCbIfQc+LEdLkGOkyRIpyB5yVC5fjKw14YSBQ8tMcgdP5y+sRpoaCdShiwoy bXihknumesgI7Mr1QO1eDQwiKvNSSmCSO5gkLrgFbQVOkC3nZihgoQdU/FEk3KKCFhVUEU/UoxDa mu+vEE2Gkxs8Rah5TobTwMOZkddEMihCfNYyW2EQJEwGQQ3hZrfZsoJvBV8Jvs75i7hC28sh4orY 8yPJE3s6rmARi79XuorON1svxvRidFK+iSv0nRo0rgBunHqSdsXiBHLdgalsYNFH2z3kXI5OoluV NFWyh24AzwTeikyv7hlYpDBTuwIL9dGLOWSmh5UGRA4TgUXsxizcSsbKwCJMkjB5Iu9j/SvrX0n/ iojNnVSKSGFIfSD22EB0AxcCHqjY2XdTEGxaUUTKkjiSRDI/jkErezx8tqmUj55KaYgt1kgZRsrT hAMe8+BtY5/ems2ZJm4UCwTaZ3GKSpm2EoLKBr6nTKV8zyGPKAqyqXnlOCl7olPzQna7afk3zQNG UZqGUB6gr77nJnHYSZ+EYRB7SPbwPOB3Lbz6sdiF11x4dRJbB+xeN5E9jDMUuyEvhKJEIHJ+rMv0 svH6scXrDWPCqqSpkjo339R8YQlvHKI9A3bc7l0BO7lf+2UC+4u+EKi4PvI3pMtRiNi9y05JUR7A bVLooVKGI9w2N2JrvoyuB/319JRL7sbuZpJ8uNgdkQLzCAPj9grV6HGHmdy2Vy40wsbuuep0cZDE FbGK2finG//0JOq9b5GoVyiyMh5NlbKHkGs/e7UDYPYiRlTlduCvmSthGiWCYGmNlDVSTxspCG7X SHWT+MPEVB7zWEDlMWSkgtAPGL+OpqAthRnzcbkcHggi6ajtlnILMH94gFm7QzaoMoMqTUwwgiqT mbBvUKWMFDd4rVYaKewiN1IcedqTZ+ahos2PRIqoV4MDP/EBlXANToTZ3a2+Ngtqs6AKte6hBYg+ FW9GC9AK8aa0gNRPUA4j0QXLDLAdZfq6EPajC6CISceNZ3IEY8xgBbxlJieNU0UFwIoepXGHCtBO 5MCV43Z+91J/tAVdTIeW1sExHBzyATpBh8igGPI7TNARph7EV6QkwyAMo07MEcepF8I3opjDVnSp fqmHTLwUUaUFxjrAGLUAEyrZxByiAOp1LpbO1mwDY2TB9gPGdiVyYo/a80BV/QB9/AQFpMEPNERG 0AJKzZCk2m2SbPRhow8ZffjbtANsalKcA+ZxjDoBP/QC2ayvEfF2HscWIIv23gdtrjTuYz1I04Ps 4R2gJ3ijlHtCZDpZs22uiFb5Lc1VGsQ+snTcXPXpcmOuGJqc8wXHmiub0Xkyo0MtAbvBlcbZBy1r 8xBc+YpaE8aACTpsZZir1JUZHRtdHUV0pYu1rLkyzVUP7QCK8WpzpVFqxQZoaAeUKd3PXBm0A99N 3NgVlG3gIGGUqNSR6h6NxgGRLG3zoeFYfGxYZVuit4cC7QCwIaDCTgkAu8s6eEsA20fexXeF84UG gWEginiaQMoi2FcPWD4AenKTbeGyLlymU/S6FEGMKRocwfaZi55GiE0AezHmexGGYmAJbkQ5sS0u e0Z+HTIm0FQcWifLdLJ6WAKiQ9/rIGyoOnekOCSwJzUGzZ69gGrbSEv7GtGGrosdJBOAkAEb8NvZ Mt15hP2OFE1C6wT8oix4eFsUoXMNDdagbCkqPFFp0LZFFp8+tro4AKYyirW2yLBFgWY4NOlUbHt9 wN8yRnDyvkXA35tO9dHsNgIdglusFGMBRWjf+JWeGyk2NlxQdLXh0ICFqC1E/SRETY6OEfrjbaMY b91BA6F/xIh6QDQBjLv0RdqokWvbQkOF/jrJbZd2c2nfpgOI7Nzw7pYL4ArLLhflwMXkVlvW2R5f fnQjoJraequTpk5qOoCG40QN5OA6iSAfcBxXycDzvCBRmRmZMGkTSm2l9eEzdFDmbyMgmvEtdU2y 5sD5lz7eRZXn12W1ckQZgKGSRooHt1BBa8IDpN021N3w6v6f5QyDoTMMleaTxNVgWjW12UVeUqkc te3v1o1SM0KMahZ1o6hPQ8toOlsztXx6u6l/zssVXY4azpyNb2Z8Zj29UPAKvMbr1TKbjP5+6vjM c+6dMJVEoWYnRH56J9eZO0g00fnM48D91bvgCP3HgZuhd0I1Xf+RsO7pnXzG+o+EJ6F3wv3pPxJu kN6Juf0HQjSo9/HSHV8Oi1+zU7jjSIBq9U7GcfBQ9G3P5rj//MZhYLh8FHjlYGT1ZORySViXGwcj jC+FN3+pKL3Yi+73jp1x8+H6Xyp89fGdBWJ7qbLaj+8sPLFLnsjEN3l8Z2EjLlUrWL6z+CP5Xal8 2VnSV3Vq/n81GVUj52oyuhLytM5qukX0VeklDfEmcXTm+A2Zo+2r8i6/LPkeNd0pCC3/9lwicbbm 8+nt1WL6Of/D3BtF2HzvWPZpW/Nj8HMQjC0afOLkrc0QVale7UO237X/xhdMc3WoQDZ1D0X5jNoM +eaXAxF+9hlQUi7+RimhODGymtxpjmW5h9gqyeOQ7GcfXxzHc/kVqQtVLHR0S+XyK88Zip37Do5H QY+Qr0r6sZI0GCuTHntu58PvZkqRqO+eGHnBf+TDNXbbe5C8U5VCN+/yCi/mZfXHyLmvsvVktPn9 NqvykbP8pdhMRhgGRTB9zd9g3BkJYGV+cmV+khVTHGoyqkdY7ejlWY13+JPbdbW4meNMjKt3URK6 eL2gZZJbTxEUyDfDTbcn69rNQJjsJrLow9RzsRSEpEToPEaZuHK0d4PutPzvJI1DkdVrnIF1JZwB h15gxcUqzO+1cgxIVeUu+wkbqS/9pdZnHFFsyR9quZ7jlXNbLSajP9G4KXA/e+nJRZTEJ8FFEJ6k sZucuCz9nEZukAbnF3/RBbJgPF/MZnnx66LInYfVstiMsRFCeewhsZY0GxKbIbGmVzX+9yMUK7WC 6Lktz/e/jeZiGJsFTrs0hiTENIjcR9YPDcek/x2miTLfypE3rZxSM8MRbFxrrIDaa7T+t+E3m8GF 9b+V9/ZoGGD9bxkuUB7E+t/W/14sl693G/Zziaz/vSmv60/TcqUiGyJQP78XCI3l6Prfum5w0JIf P6RZgwI2QG4q8FE1x2Ng5Qy0Sn6s/w0MczE97E6joiMyuYvW/zb9b81GbfxvXRylvWygFetfy+l/ Nvv73+h1gI6ggqgTgACOoLetctb/NsIGi39b/JugNNI3i39b/Dsbz/Ns9qWYcS+lzhZLvHbqr2tk HOtqgWTTEiAuUiurfAYwNy/EKyE+j8B2bvrlvbrZGcA2zEt1c3W2rJy7DKkki3+vgcU/BxB9mf9N mR3hfzdsX2yDkJBbBGO/ZzcKXcMrqLWtg9GbZ+XH/TRAbYkoEEOxGCb3dfA5FjJQeWXpCfBxuTYq dE6h3RIQf8/GSHQp59lmLqR583VzXtbC16nKW6nCR6fORp5AY/wXCNa5AUNYpX7z1AHPApFYCNET HjktViQuwyWEaMpXJyDFpkYfhksI+UlMxEie7sWIZcYEXadJCAWoj6QOT9ThjyUBEnWPy79NCD2a YnX5j7yFLUu0WtR55SwXq8kII7PwIzS3R1+5cdWyTvksJePqd5+s1w+Kt6yhDxuQGgFpCMe/q5Nd 4v0wSdrATZmbijjEd1EyJkY879JJdEhW/voOm2R18sPrpIY+rE6aOgnDs+U4cves5etxLtlvAihy ivJsjrAk58WglzxQEcS31p882z0kknIUC+oamjWFkcudzUYZrXsordnHjPYO0j0EQadrirjbJUV4 OPfQ8+MwRpMAzgZEESPoC8ItUfmKIAEdEOCqdQ/N9NQhd88QTFCSNGuKTFOk+foGhqFLG16GYSgm v4A9nm+KjPkxLAxZ2h0QbU2RNUXr8enpZjrPV9nmU2953wuhu23qKvr9vwdS4WEmekBt2AmICGKG cTDWFNVPPu6DNkUaE7OmyDRFmrpqmCKTu/oCOH1PU+SjjjP1BGyYpNBMjpTYoOhAUmAHGRRtk7hE hdXgQREYXAnN7YAhStBasNtVwCLmx9bEqRn0Yu2QaYc0hcuwQxrIHCQk8jHiQ01uZzGKlzEtEM6p NUTWECGf+zZshkizGXQzDWx6j5AIhcCuj0lNPCQCNB132cTWFB2dKdLZD2uKDFNESiAQc94sXUwv MxxDXnfRSRD9VFXlPaXXwXlqZYgIXhf8EGKKPKPBRuAyWZKPon/kbmXVvMbIUdBMF/jcIYlHO+6z mUBkhdcU3m3mQfQ+zANMqw181dQSEwID1WFCi3KLDWSZB4dfniLaltJSaXXS1EnNPGicPG16ZXnK MGwg3w9BPxUtGyKM4A14hNVEOG0fD16g6i9jyUDFjagRXGWLgpPUMfU05N0qWsy7FgecU+8Un6q1 22AEvWbykVVJUyU1K6KBGyKTFvEC2BvE//oMzbJohAsD1dKYYADNappGk9u235So3qbRzIvQ/VDA 5mnqRmg31UYr3CTFV+KeIhpBYEovfY5CnB26/J5kc0spF91oPgilnKaMdalywhTIMOjbaMdL8kX9 KgByq/eICniJGykVSOMAPcc+rAbYcgvZUumjl1tE2yQGbHoPxC6U8wCJw4DmVOCWtg1A25mz1RZH EF/pxLx15kxnTnMYmvhK36lh46vITRi4RASix0jsRlvxlclwtZDHEaikLYDK1tsdqaNtggU2vYeV RFFiitJ70kgPLfOCbsc8Szo/urSWpg1YK2layR6GhbBPLw/qXh25IYflApDgWhm6caoqVFVuwMMm jGXk4AWGXgt67sfELmzkdiCRW7zNtcCm97BJxHelcfJkk/omvdvI7dhskqiqtpkx1aRFDi6hVsWd 4kRseg+VRG1iKA0S5i+6VKeIyzAzY2bkZsGUw4/cmhGh1k003MRYE0iazBi2NTr5Auz/9W5igDYy cAMJ4owxqBtGs6WV1k2c0Q15fKrBO7ZHO8TakHibrYFNjfwPWTAfUYskLv0JeoklnQyvhS6Ozk3U C621SaZN0mwNDfCL2gyJXAynkhh4l8jRWD74FwF6AbcMko3cjk4l9dpvVdJUyR6KSDxAC4teHgjM JA2XIkMJhiN8xk4m3IPSEk2ESPMWTeRB7fbwK+smvmgOBLXx6kIX78MDYSjVCgWW7gdgBYoCMgtd PN665JB7WTTztq1NMm3SNg9ENF1/VzcxSWIf3S06bqJFE6uyO4jnoFVS+z5WJU2V1DwQA000iSBD oolRik64sv9gClZIt+mTRRMtmvh0E6yX9TxDi/8tN1HzUwblJsJNZOjHSEFS4FIrTtt988in9WJU tIStrU0ybFKieSC8vh9v2+D+W9b3e5iQEKPVFIcqkgRD+Tp55pCFKaa8cajC9+JYeI67mU9HW98f aAa3FV5TeDVjonGoRNOwl7P4WtWJpBX7VSeSvmC2ooPx017K0NRcYhERSq5E8wwDi0DVLCwi7/CM fRl3BXdL93vWJFpe34Hw+pAW3apWFKnSl6vESxgLhtxj7hOxhsSynvqRiyk3rYDfdlOm+2F5Ct+w m3KyzVPAprYrM1BXiST2fNXYP3Z973HynC17OgLynMZwrHdmemfbRIWE5yIHR6Ax98mLUeskAg3i tnYCDUseOjqmgsaVrE6aOqmZCpo8JIDfwXUS45/8hOaXEk+BsSAScxqN6Kg1AMfaycO3k81kWquT pk5ukycSDVYOioqDGhT4obCTgZ9iKluHYh4nrh5KhV4zlEASkcyONkp2PuJHn4/YTMe1OmnqpGZP XFR5fl1WKyfRGKzUSQMaJyUwLOgLety2VI7P4enQ9XzoHFWGEUoIPl8qwloDJZzebuqf83JFl5Pd gcqGi8nGNzNJaruZqZQbbO31aplNRn8/dXzmOfdOmMqTNTvhTHon15k7oZhaRgdUxwHCpHfBEfqP g0VE7+QFYf+RECDoneAD9B8JHoveKfT8/iNhCdU7Mbf/QHikeh8wTvoPhGxEs1O440gAbfVOxnHw UPRtz+bqSUwfCvko8MrBAM3JyOWtEtflhmDiS+EDXYpOyXziJj3AHTvj5kMQLjm2gfNhr0d2FizQ S9Xr7vGdRQnuJZfyJ48skjaXavnnRxZ/JL8rrfzOkr6qU/P/q8moGjlXk9GVAAPXWU23iK6eXjr3 kxGJozPHb8gcbV+Vd/llyfeo6U5BaPm3V53Lms+nt1eL6ef8D3PvQBoylVRa82Pwc+AOop+0vI7W ZoiqtGjtQ7bftQ/liykW+B78UOgdz68yVC1+xWbIt9js6WfXuui+M6BPsPgbpYTiUJ70mgWfS50X Dd1INCDZz/4G8i9cic/Ko8sDBa0b5ElXve/gePD0CDmkqR8rSYOxMunip2y8LOhhv6pj6BG3SGx1 Rm01UL3gP/LhGrudZnpk+cv6xTlVKXTzLq/wYl5Wf6CZa5WtJ6PN77dZlWPWxS8Fmrij8Ao1207N 36DnOglgZX5yZX6SFVMcajKqR1jt6OVZjXf4k9t1tbiZ40yMq3dRUtbuekEGi1tP4YHIN/ebtTCj eOE8rJbFm42dIDJ8t8EjtuGqpEl/AS3LbH/qw+DwJCI3sso/EAejIz+rBz5ccJCYcSQy/17kxl2X HPeVXIMQP6KpEBRvhzf+ngnEI9ZYvbTtrYhKAQaU+W0mVqIRs2FjTgYrB5tFAs7g4NJIcNwPiwMd L2M/tIWdfW3iSAk6RTTClzMiy2FymMBmA9JDbnR6mSsJ+uXDbHLqSmKx2SPAZnW23OJABg6UaoaZ zpdgU+MaDlds7Rl20kfdZixW0V120o6rOAKd1Nlyq5OmTgIF6sZrqXYp4LzuGa9hxp+I15QD2kyr INPMQzl+mpeEcrxE+98q5FXMUDP3mSSY8twpP/CQhmEI+rh9RXJU1Dh+zMjOUkMPhBqabnPksOk9 bJnP/CSQncE9hjExbifpgQ+xh/Uvr+tP03J1imVjMc1PD7kkFDX5UtKsLTNtGYS8G/Npqz8oDuO7 yPzTwCbKIfioVeh2IW5z5NATUiWsdqCNNvcPEMuA6fGmurk6W1bOXUaJMf5DSgGz3tptsHFooWaZ WJ00dVJz5JqqIjEv7OX5gFe7ij5DYy0Ms+Fq6UVo6MNh2ibsw6cRvF/pKnpyyoZ1FSWCfFstJqM/ Uev+JfmSBCe4WV9OAvf8/OSni7PgJLpAr6Rz//zs7Jz9RUmpViZNpp2wEcmxvcpjCcc+xPQA9eMW ZolXhYpOowYMSd9r80ZTnynJFStD5KUAFzvOISZ1xqQRnBHDIib6lu+W+KOtCg01I8mu3+b6jcDZ FF59l7Z5W05Rns1Bycm/2chyFP9g7JHIZmHCSiw4r81yHdiR5Q+AUpCw1hl2K7ym8Goyglh59V0a QHh9OBopaux5KjZMUuZy1WmEF/X4DFCVWHm/53p8UT9EBtEKrym8mlUghLfLKHhLt4FFETr/CY6d n/jIWnKs1hBeQEoE8X73boNoiWiFV9G75PgNPq3a8BskADKQ18vQKyKktRXwS+yifr7j9AbAZigj T9L7nMqLo3V6RRONQ5JeYADTMf5xpOcG9Mr5Ynqe1Zn5npMex7lXzsvlLK9+/H8BAAAA//8DAFBL AwQUAAYACAAAACEAqOUehNsAAAAGAQAADwAAAGRycy9kb3ducmV2LnhtbEyPQUvDQBCF74L/YRnB m52tpSHGbIoIHjwomAi9bnfHJDQ7G7PbNv57t17s5cHjDe99U25mN4gjTaH3rGC5kCCIjbc9two+ m5e7HESImq0ePJOCHwqwqa6vSl1Yf+IPOtaxFamEQ6EVdDGOBWIwHTkdFn4kTtmXn5yOyU4t2kmf Urkb8F7KDJ3uOS10eqTnjsy+PjgF72vcfjcPPdfZ22prXGOwfc2Vur2Znx5BRJrj/zGc8RM6VIlp 5w9sgxgUpEfin54zKfPkdwrW2UoCViVe4le/AAAA//8DAFBLAQItABQABgAIAAAAIQC2gziS/gAA AOEBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ADj9If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AA5C2Ha7GwAAX00BAA4AAAAAAAAAAAAAAAAALgIAAGRycy9lMm9Eb2MueG1sUEsBAi0AFAAGAAgA AAAhAKjlHoTbAAAABgEAAA8AAAAAAAAAAAAAAAAAFR4AAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA BAAEAPMAAAAdHwAAAAAAABDwBAAAAAAAAAAAABHwBAAAAAEAAAAPAATwfgAAALIECvAIAAAAAwQA AAIKAABTAAvwNAAAAFgBAAAAAL8BAQARAP8BAAAIAIDDFgAAAL8DAAACAEMAYQBuAHYAYQBzACAA MQAwADEAAAATACLxBgAAAKoDAAQADwAAD/AQAAAAKI/u//WP7v9XKnQArKJ6AAAAEfAEAAAAAQAA AA8ABPA0BQAAogwK8AgAAAAEBAAAAgoAAIMAC/BGAAAAfwAAAO8BgAAAAAEAvwAAAAYAvwEQABAA /wEAABgAPwMAAAgAgMMWAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANQAAACMAIvGeBAAAqcOS BAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht bJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNF tt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8T pjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQ Zudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz 4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABf cmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+ 8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9a ix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6i asfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYA CAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQ UkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAA ACEARtCoI8IAAADaAAAADwAAAGRycy9kb3ducmV2LnhtbESP0YrCMBRE3wX/IVxhX2RNddVq1yju guKrrh9w21zbss1NaaKtf28EwcdhZs4wq01nKnGjxpWWFYxHEQjizOqScwXnv93nAoTzyBory6Tg Tg42635vhYm2LR/pdvK5CBB2CSoovK8TKV1WkEE3sjVx8C62MeiDbHKpG2wD3FRyEkVzabDksFBg Tb8FZf+nq1FwObTD2bJN9/4cH6fzHyzj1N6V+hh0228Qnjr/Dr/aB63gC55Xwg2Q6wcAAAD//wMA UEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5 cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3Jl bHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJz L3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBG0KgjwgAAANoAAAAPAAAAAAAAAAAAAAAAAJgC AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhwMAAAAAAAAP8BAAAADs3g8AsnwGAOp9 HACt2QkAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAEADwAE8CwFAAAyAArwCAAAAAUEAAACCgAAgwAL 8D4AAAB/AAAA7wGAAAAAAgC/AAAABgC/ARAAEAD/AQgAGAA/AwAACACAww4AAAC/AwAAAgBPAHYA YQBsACAANgAAACMAIvGeBAAAqcOSBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlY d9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvE IrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlk EA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8Y KGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7 CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg 372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9u A+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1 x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54 bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK3 4+UCAAAA//8DAFBLAwQUAAYACAAAACEAsHgn2cIAAADaAAAADwAAAGRycy9kb3ducmV2LnhtbESP QWvCQBSE74X+h+UVvNWNjUpJXUUqgh48NLb3R/aZBLNvQ/YZ4793BaHHYWa+YRarwTWqpy7Ung1M xgko4sLbmksDv8ft+yeoIMgWG89k4EYBVsvXlwVm1l/5h/pcShUhHDI0UIm0mdahqMhhGPuWOHon 3zmUKLtS2w6vEe4a/ZEkc+2w5rhQYUvfFRXn/OIMbMp1Pu91KrP0tNnJ7Px32KcTY0Zvw/oLlNAg /+Fne2cNTOFxJd4AvbwDAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCweCfZwgAA ANoAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhwMA AAAAAAAP8BAAAAA3uRsAJEwBACPyIQCyfAYAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAIADwAE8DYF AAACAgrwCAAAAAYEAABCCwAAgwAL8EgAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAAAAA/ AwgACACAwxgAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADcAAAAjACLxqgQAAKnDngQAAKoD AAQAD1BLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1O xCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwu KykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoV jf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0 +EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc +MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3Jl bHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a 7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/Wqth xOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2oj f9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYA CAAAACEAMy8FnkEAAAA5AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NV MtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAG AAgAAAAhAAl9hRLBAAAA2gAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrAjEUhO8F/0N4BW/dbAvW shpFBUG8SLWgx8fmuRvcvCybdLP+e1MoeBxm5htmvhxsI3rqvHGs4D3LQRCXThuuFPyctm9fIHxA 1tg4JgV38rBcjF7mWGgX+Zv6Y6hEgrAvUEEdQltI6cuaLPrMtcTJu7rOYkiyq6TuMCa4beRHnn9K i4bTQo0tbWoqb8dfq8DEg+nb3Sau9+eL15HMfeKMUuPXYTUDEWgIz/B/e6cVTOHvSroBcvEAAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAxAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAuAgAA ZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEACX2FEsEAAADaAAAADwAAAAAAAAAA AAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAI8DAAAAAAAAD/AQAAAA0O0U AJ59BgDa1B4AbrQKAAAAEfAEAAAAAQAAAA8ABPAoBQAAMgAK8AgAAAAHBAAAAgoAAIMAC/A+AAAA fwAAAO8BgAAAAAMAvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMOAAAAvwMAAAIATwB2AGEAbAAg ADgAAAAjACLxmgQAAKnDjgQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/ LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsY Ugr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HS pQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9T FsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxj y1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1O NGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V /IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2 DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGv yM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAA AP//AwBQSwMEFAAGAAgAAAAhADE1Ldy+AAAA2gAAAA8AAABkcnMvZG93bnJldi54bWxET02LwjAQ vQv7H8IseNNUiyJdo4gi6GEPW9370IxtsZmUZqz135vDwh4f73u9HVyjeupC7dnAbJqAIi68rbk0 cL0cJytQQZAtNp7JwIsCbDcfozVm1j/5h/pcShVDOGRooBJpM61DUZHDMPUtceRuvnMoEXalth0+ Y7hr9DxJltphzbGhwpb2FRX3/OEMHMpdvux1Kov0djjJ4v77fU5nxow/h90XKKFB/sV/7pM1ELfG K/EG6M0bAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAA AAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAA AAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAxNS3cvgAAANoAAAAPAAAA AAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAgwMAAAAAAAAP8BAA AACXPCwAG4ALAJ9CNAC86A8AAAAR8AQAAAABAAAAAAAN8AQAAAAAAAMADwAE8DgFAAACAgrwCAAA AAgEAAACCwAAgwAL8EgAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAAAAA/AwgACACAwxgA AAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADkAAAAjACLxrAQAAKnDoAQAAKoDAAQAD1BLAwQU AAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPh alqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3f t0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpV NmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L 5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9 wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOk kD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwO Nk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l +VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBx EEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8F nkEAAAA5AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvO T8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAKF/ 2QHDAAAA2gAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAUhO+F/oflFXprNnooJrpKKSiieKhK 0Nsj+0yC2bdhd9Xor+8WCh6HmfmGmcx604orOd9YVjBIUhDEpdUNVwr2u/nHCIQPyBpby6TgTh5m 09eXCeba3viHrttQiQhhn6OCOoQul9KXNRn0ie2Io3eyzmCI0lVSO7xFuGnlME0/pcGG40KNHX3X VJ63F6PgsM4uxb3Y0KoYZKsjOuMfu4VS72/91xhEoD48w//tpVaQwd+VeAPk9BcAAP//AwBQSwEC LQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29u bmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQChf9kBwwAAANoAAAAPAAAAAAAAAAAAAAAAAKEC AABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAAkQMAAAAAAAAP8BAAAACu1R4AsnwGADlB MAAbgAsAAAAR8AQAAAABAAAADwAE8DYFAACiDArwCAAAAAkEAAACCgAAgwAL8EgAAAB/AAAA7wGA AAAABAC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgA IAAxADAAAAAjACLxngQAAKnDkgQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAA AFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff 3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7 HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAP B+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChr yr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAA IQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpb SUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9 v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPq fE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9ces FzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1s srGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+Pl AgAAAP//AwBQSwMEFAAGAAgAAAAhAI1h+33CAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj81u wkAMhO9IfYeVK/WCYNOK38CCWiQQV34ewGRNEpH1RtktCW+PD0jcbM145vNy3blK3akJpWcD38ME FHHmbcm5gfNpO5iBChHZYuWZDDwowHr10Vtian3LB7ofY64khEOKBooY61TrkBXkMAx9TSza1TcO o6xNrm2DrYS7Sv8kyUQ7LFkaCqxpU1B2O/47A9d92x/P28sunqeH0eQPy+nFP4z5+ux+F6AidfFt fl3vreALvfwiA+jVEwAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAA AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsA AAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAA AAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAjWH7fcIAAADb AAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIcDAAAA AAAAD/AQAAAA48okANfsBADhaTEA0kkIAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAEAA8ABPA0BQAA ogwK8AgAAAAKBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAAAUAvwAAAAYAvwEQABAA/wEAABgAPwMA AAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQAxAAAAIwAi8ZwEAACpw5AEAACqAwAE AA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQw EMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ 5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb 7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18 lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/ s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5y ZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZ sniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo 1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlS MA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAz LwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/J zEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQDiLV7m wAAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRE/NasJAEL4LfYdlCl6kbhSNbXQTqlDxauoDjNkx CWZnQ3Zr4tt3BcHbfHy/s8kG04gbda62rGA2jUAQF1bXXCo4/f58fIJwHlljY5kU3MlBlr6NNpho 2/ORbrkvRQhhl6CCyvs2kdIVFRl0U9sSB+5iO4M+wK6UusM+hJtGzqMolgZrDg0VtrSrqLjmf0bB 5dBPll/9ee9Pq+Mi3mK9Otu7UuP34XsNwtPgX+Kn+6DD/Bk8fgkHyPQfAAD//wMAUEsBAi0AFAAG AAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQDiLV7mwAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhQMAAAAAAAAP8BAAAACR8Q0At0UTALO9GgBIOBYAAAAR 8AQAAAABAAAAAAAN8AQAAAAAAAUADwAE8DMFAACiDArwCAAAAAsEAAACCgAAgwAL8EgAAAB/AAAA 7wGAAAAABgC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBv AHgAIAAxADIAAAAjACLxmwQAAKnDjwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZ WHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0L xCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJp ZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUP GChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAI AAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksH uwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJ YN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CP bgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr 9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwu eG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVay t+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhABL/wJG/AAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxE T8uqwjAQ3Qv+QxjBjWiqXF/VKF5BcVv1A8ZmbIvNpDS5tv69uSC4m8N5znrbmlI8qXaFZQXjUQSC OLW64EzB9XIYLkA4j6yxtEwKXuRgu+l21hhr23BCz7PPRAhhF6OC3PsqltKlORl0I1sRB+5ua4M+ wDqTusYmhJtSTqJoJg0WHBpyrGifU/o4/xkF91MzmC6b29Ff58nP7BeL+c2+lOr32t0KhKfWf8Uf 90mH+RP4/yUcIDdvAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAA AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsA AAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAA AAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAEv/Akb8AAADb AAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIQDAAAA AAAAD/AQAAAAgAQWALzoDwAvyiIA2tQSAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAGAA8ABPAsBQAA MgAK8AgAAAAMBAAAAgoAAIMAC/BAAAAAfwAAAO8BgAAAAAcAvwAAAAYAvwEQABAA/wEIABgAPwMA AAgAgMMQAAAAvwMAAAIATwB2AGEAbAAgADEAMwAAACMAIvGcBAAAqcOQBAAAqgMABAAPUEsDBBQA BgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYq baoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7W T8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTe JXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzO Fxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu 9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrD MAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuK omXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMe dEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w 09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5 AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHT tVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEApG0yI8AAAADbAAAA DwAAAGRycy9kb3ducmV2LnhtbERPTWvCQBC9C/0PyxS8mY0NiqSuIhVBDz006n3IjkkwOxuy05j+ +65Q6G0e73PW29G1aqA+NJ4NzJMUFHHpbcOVgcv5MFuBCoJssfVMBn4owHbzMlljbv2Dv2gopFIx hEOOBmqRLtc6lDU5DInviCN3871DibCvtO3xEcNdq9/SdKkdNhwbauzoo6byXnw7A/tqVywHncki u+2PsrhfP0/Z3Jjp67h7ByU0yr/4z320cX4Gz1/iAXrzCwAA//8DAFBLAQItABQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwEC LQAUAAYACAAAACEApG0yI8AAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1s UEsFBgAAAAAEAAQA9QAAAIUDAAAAAAAAD/AQAAAA7N4PAMAHIwAtrBYAWXIoAAAAEfAEAAAAAQAA AAAADfAEAAAAAAAHAA8ABPA1BQAAogwK8AgAAAANBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAAAgA vwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMQA0 AAAAIwAi8Z0EAACpw5EEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29u dGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7i Ch5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK 91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUA QxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbM iQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1f YdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tY Jm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRh qUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyH HbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8A AAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jN UShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD/ /wMAUEsDBBQABgAIAAAAIQDyWv1+wQAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRE/NasJAEL4X +g7LFLwU3VRsbKObUAuK10QfYMyOSTA7G7KriW/fFYTe5uP7nXU2mlbcqHeNZQUfswgEcWl1w5WC 42E7/QLhPLLG1jIpuJODLH19WWOi7cA53QpfiRDCLkEFtfddIqUrazLoZrYjDtzZ9gZ9gH0ldY9D CDetnEdRLA02HBpq7Oi3pvJSXI2C8354//weTjt/XOaLeIPN8mTvSk3exp8VCE+j/xc/3Xsd5i/g 8Us4QKZ/AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAA AAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAA AAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA8lr9fsEAAADbAAAADwAA AAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIYDAAAAAAAAD/AQ AAAATx0KAHOVHgCABBYAwAcjAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAIAA8ABPA5BQAAAgIK8AgA AAAOBAAAAgsAAIMAC/BKAAAAfwAAAOsBvwEAABAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMa AAAAvwMAAAIAQQB1AHQAbwBTAGgAYQBwAGUAIAAxADUAAAAjACLxqwQAAKnDnwQAAKoDAAQAD1BL AwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8m vgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAe ey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaib qrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHV rw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/z W7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJl bHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguK TkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxU k54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rx MmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEA My8FnkEAAAA5AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJI zUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAh AM92S+HCAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxET02LwjAQvQv+hzCCN01dUNZqFBFWRPGw upT1NjSzbdlmUpKo1V9vhIW9zeN9znzZmlpcyfnKsoLRMAFBnFtdcaHg6/QxeAfhA7LG2jIpuJOH 5aLbmWOq7Y0/6XoMhYgh7FNUUIbQpFL6vCSDfmgb4sj9WGcwROgKqR3eYrip5VuSTKTBimNDiQ2t S8p/jxej4Hs/vWT37EC7bDTdndEZ/zhtlOr32tUMRKA2/Iv/3Fsd54/h9Us8QC6eAAAA//8DAFBL AQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9j b25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAM92S+HCAAAA2wAAAA8AAAAAAAAAAAAAAAAA oQIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACQAwAAAAAAAA/wEAAAAKdFEwDYsRwA qEUTAMgHIwAAABHwBAAAAAEAAAAPAATwOgUAAAICCvAIAAAADwQAAAILAACDAAvwSgAAAH8AAADr Ab8BAAAQANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEA cABlACAAMQA2AAAAIwAi8awEAACpw6AEAACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEA ABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQ Buvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTb fQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68k CUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo 2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQU AAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5s hawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/Qz Ezq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3Ypp DtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5 qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29u bmVjdG9yeG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nM yc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQA/pNWWwwAAANsAAAAPAAAAZHJzL2Rv d25yZXYueG1sRE9Na8JAEL0L/odlhN50Yw9SU1cpgqWk9KApod6G7JiEZmfD7mqS/nq3UOhtHu9z NrvBtOJGzjeWFSwXCQji0uqGKwWf+WH+BMIHZI2tZVIwkofddjrZYKptz0e6nUIlYgj7FBXUIXSp lL6syaBf2I44chfrDIYIXSW1wz6Gm1Y+JslKGmw4NtTY0b6m8vt0NQq+3tfXYiw+KCuW6+yMzvif /FWph9nw8gwi0BD+xX/uNx3nr+D3l3iA3N4BAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA 6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA lgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA My8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAU AAYACAAAACEAP6TVlsMAAADbAAAADwAAAAAAAAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsF BgAAAAAEAAQA+QAAAJEDAAAAAAAAD/AQAAAA0O0UANgcDwAOPh0AdpoVAAAAEfAEAAAAAQAAAA8A BPAtBQAAMgAK8AgAAAAQBAAAAgoAAIMAC/BAAAAAfwAAAO8BgAAAAAkAvwAAAAYAvwEQABAA/wEI ABgAPwMAAAgAgMMQAAAAvwMAAAIATwB2AGEAbAAgADEANwAAACMAIvGdBAAAqcORBAAAqgMABAAP UEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH 74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0 N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ 3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUx QP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7Pb bHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4 jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8F nkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxL t1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEA21Y0IMEA AADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPTWvCQBC9C/0Pywi96UaDtkRXkUrBHjw0tvchOybB 7GzIjjH+e7cg9DaP9znr7eAa1VMXas8GZtMEFHHhbc2lgZ/T5+QdVBBki41nMnCnANvNy2iNmfU3 /qY+l1LFEA4ZGqhE2kzrUFTkMEx9Sxy5s+8cSoRdqW2HtxjuGj1PkqV2WHNsqLClj4qKS351Bvbl Ll/2OpVFet4fZHH5PX6lM2Nex8NuBUpokH/x032wcf4b/P0SD9CbBwAAAP//AwBQSwECLQAUAAYA CAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL AQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwu eG1sUEsBAi0AFAAGAAgAAAAhANtWNCDBAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3du cmV2LnhtbFBLBQYAAAAABAAEAPUAAACGAwAAAAAAAA/wEAAAANhMGgDAByMAGRohAMraJwAAABHw BAAAAAEAAAAAAA3wBAAAAAAACQAPAATwNgUAAKIMCvAIAAAAEQQAAAIKAACDAAvwSAAAAH8AAADv AYAAAAAKAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8A eAAgADEAOAAAACMAIvGeBAAAqcOSBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlY d9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvE IrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlk EA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8Y KGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7 CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg 372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9u A+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1 x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54 bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK3 4+UCAAAA//8DAFBLAwQUAAYACAAAACEAcxf3e8IAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP zW7CQAyE70h9h5Ur9YJg04rfwIJaJBBXfh7AZE0SkfVG2S0Jb48PSNxszXjm83LduUrdqQmlZwPf wwQUceZtybmB82k7mIEKEdli5ZkMPCjAevXRW2JqfcsHuh9jriSEQ4oGihjrVOuQFeQwDH1NLNrV Nw6jrE2ubYOthLtK/yTJRDssWRoKrGlTUHY7/jsD133bH8/byy6ep4fR5A/L6cU/jPn67H4XoCJ1 8W1+Xe+t4Aus/CID6NUTAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBzF/d7wgAA ANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhwMA AAAAAAAP8BAAAADnMhUAXkUbABgaIQCrtx8AAAAR8AQAAAABAAAAAAAN8AQAAAAAAAoADwAE8DkF AAACAgrwCAAAABIEAAACCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAAAAA/ AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADEAOQAAACMAIvGrBAAAqcOfBAAA qgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1 vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mY ehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYe NDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3Dn Slz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABf cmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8 L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9a q2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CP aiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQA BgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszP s1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQU AAYACAAAACEATjtB5MIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPTWvCQBC9C/0PyxR60016 KE10DaWgFKWHqgS9DdlpEpqdDburRn99VxC8zeN9zqwYTCdO5HxrWUE6SUAQV1a3XCvYbRfjdxA+ IGvsLJOCC3ko5k+jGebanvmHTptQixjCPkcFTQh9LqWvGjLoJ7YnjtyvdQZDhK6W2uE5hptOvibJ mzTYcmxosKfPhqq/zdEo2K+zY3kpv2lVptnqgM7463ap1Mvz8DEFEWgID/Hd/aXj/Axuv8QD5Pwf AAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAx AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAu AgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEATjtB5MIAAADbAAAADwAAAAAA AAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAJADAAAAAAAAD/AQAAAA o7IdAMwMGgCksh0AyAcjAAAAEfAEAAAAAQAAAA8ABPAwBQAAogwK8AgAAAATBAAAAgoAAIMAC/BI AAAAfwAAAO8BgAAAAAsAvwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgA dAAgAEIAbwB4ACAAMgAwAAAAIwAi8ZgEAACpw4wEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9 AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9g SKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0x rJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5J PG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZn nDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBL AwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZ o05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC 0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZA t2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRET fVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3No YXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9L tVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQBDDTHAvAAAANsAAAAPAAAAZHJzL2Rvd25y ZXYueG1sRE9LCsIwEN0L3iGM4EY0VfxWo6iguPVzgLEZ22IzKU209fZmIbh8vP9q05hCvKlyuWUF w0EEgjixOudUwe166M9BOI+ssbBMCj7kYLNut1YYa1vzmd4Xn4oQwi5GBZn3ZSylSzIy6Aa2JA7c w1YGfYBVKnWFdQg3hRxF0VQazDk0ZFjSPqPkeXkZBY9T3Zss6vvR32bn8XSH+exuP0p1O812CcJT 4//in/ukFYzC+vAl/AC5/gIAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8B AAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkA AAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAEMNMcC8 AAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACB AwAAAAAAAA/wEAAAAFBDHwBG8BsAOkgtAPCxIQAAABHwBAAAAAEAAAAAAA3wBAAAAAAACwAPAATw LwUAADIACvAIAAAAFAQAAAIKAACDAAvwQAAAAH8AAADvAYAAAAAMAL8AAAAGAL8BEAAQAP8BCAAY AD8DAAAIAIDDEAAAAL8DAAACAE8AdgBhAGwAIAAyADEAAAAjACLxnwQAAKnDkwQAAKoDAAQAD1BL AwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C 7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW 9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U 1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+ 2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7 o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOk kMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G 1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85 YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QM uCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5B AAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dV Cg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAPWfw3LDAAAA 2wAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAUhO9C/8PyCt50E4NSUleRiqAHD43t/ZF9JsHs 25B9jem/7wpCj8PMfMOst6Nr1UB9aDwbSOcJKOLS24YrA1+Xw+wNVBBki61nMvBLAbabl8kac+vv /ElDIZWKEA45GqhFulzrUNbkMMx9Rxy9q+8dSpR9pW2P9wh3rV4kyUo7bDgu1NjRR03lrfhxBvbV rlgNOpNldt0fZXn7Pp+y1Jjp67h7ByU0yn/42T5aA4sUHl/iD9CbPwAAAP//AwBQSwECLQAUAAYA CAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL AQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwu eG1sUEsBAi0AFAAGAAgAAAAhAPWfw3LDAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3du cmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAAAA/wEAAAAMH2DgAggjAAbGoXACpVNQAAABHw BAAAAAEAAAAAAA3wBAAAAAAADAAPAATwLwUAADIACvAIAAAAFQQAAAIKAACDAAvwQAAAAH8AAADv AYAAAAANAL8AAAAGAL8BEAAQAP8BCAAYAD8DAAAIAIDDEAAAAL8DAAACAE8AdgBhAGwAIAAyADIA AAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250 ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIK Hmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3 UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBD GK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJ C991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gm bd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGp RzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/Icd vM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAA AP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1R KEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP// AwBQSwMEFAAGAAgAAAAhAAVNXQXDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAUhO9C /8PyCt50Y4JSUleRiqAHD43t/ZF9JsHs25B9jem/7wpCj8PMfMOst6Nr1UB9aDwbWMwTUMSltw1X Br4uh9kbqCDIFlvPZOCXAmw3L5M15tbf+ZOGQioVIRxyNFCLdLnWoazJYZj7jjh6V987lCj7Stse 7xHuWp0myUo7bDgu1NjRR03lrfhxBvbVrlgNOpNldt0fZXn7Pp+yhTHT13H3DkpolP/ws320BtIU Hl/iD9CbPwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAA AAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAA AAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAAVNXQXDAAAA2wAAAA8A AAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAAAA/w EAAAAD97GQA39jAAI/IhAEHJNQAAABHwBAAAAAEAAAAAAA3wBAAAAAAADQAPAATwNwUAAKIMCvAI AAAAFgQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAOAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDD GAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADIAMwAAACMAIvGfBAAAqcOTBAAAqgMABAAPUEsD BBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74Lv EOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1 Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTV rdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7a sFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj +ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQ wWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbW TQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlg qWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4 LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEA AAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UK DXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAs9+vt8MAAADb AAAADwAAAGRycy9kb3ducmV2LnhtbESP3YrCMBSE74V9h3AWvJE1Xf+62zWKCoq3/jzAaXNsyzYn pYm2vr0RBC+HmfmGmS87U4kbNa60rOB7GIEgzqwuOVdwPm2/fkA4j6yxskwK7uRgufjozTHRtuUD 3Y4+FwHCLkEFhfd1IqXLCjLohrYmDt7FNgZ9kE0udYNtgJtKjqJoJg2WHBYKrGlTUPZ/vBoFl307 mP626c6f48NktsYyTu1dqf5nt/oD4anz7/CrvdcKRmN4fgk/QC4eAAAA//8DAFBLAQItABQABgAI AAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54 bWxQSwECLQAUAAYACAAAACEAs9+vt8MAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA9QAAAIgDAAAAAAAAD/AQAAAA/MQKAAO6KgAtrBYAUCwvAAAAEfAE AAAAAQAAAAAADfAEAAAAAAAOAA8ABPA6BQAAAgIK8AgAAAAXBAAAQgsAAIMAC/BKAAAAfwAAAOsB vwEAABAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMaAAAAvwMAAAIAQQB1AHQAbwBTAGgAYQBw AGUAIAAyADQAAAAjACLxrAQAAKnDoAQAAKoDAAQAD1BLAwQUAAYACAAAACEA/iXrpQABAADqAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG 6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9 BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJ RpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZ AMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQA BgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyF rCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMT Oriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO 0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmo jpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAGRycy9jb25u ZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJ z0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAAYt3OXDAAAA2wAAAA8AAABkcnMvZG93 bnJldi54bWxEj09rAjEUxO8Fv0N4Qm/dbKUWWY1ShYL0UvwDenxsnrvBzcuyiZv12zeC0OMwM79h FqvBNqKnzhvHCt6zHARx6bThSsHx8P02A+EDssbGMSm4k4fVcvSywEK7yDvq96ESCcK+QAV1CG0h pS9rsugz1xIn7+I6iyHJrpK6w5jgtpGTPP+UFg2nhRpb2tRUXvc3q8DEX9O3201c/5zOXkcy96kz Sr2Oh685iEBD+A8/21utYPIBjy/pB8jlHwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADq AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCW BTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAz LwWeQQAAADkAAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQA BgAIAAAAIQAGLdzlwwAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUG AAAAAAQABAD5AAAAkQMAAAAAAAAP8BAAAAA0MhMAWnIoAI1FEwAhgjAAAAAR8AQAAAABAAAADwAE 8DcFAACiDArwCAAAABgEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAADwC/AAAABgC/ARAAEAD/AQAA GAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAAyADUAAAAjACLxnwQAAKnDkwQA AKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyU kc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbe KbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8 xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbn XsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HG f7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3Jl bHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv 9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosd KaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH 13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgA AAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJI zUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAh AFN6kljDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj91qwkAUhO8LvsNyhN4U3Sj1L7oJttCS 26gPcMwek2D2bMiuJnn7bqHQy2FmvmEO6WAa8aTO1ZYVLOYRCOLC6ppLBZfz12wLwnlkjY1lUjCS gzSZvBww1rbnnJ4nX4oAYRejgsr7NpbSFRUZdHPbEgfvZjuDPsiulLrDPsBNI5dRtJYGaw4LFbb0 WVFxPz2MglvWv612/fXbXzb5+/oD683Vjkq9TofjHoSnwf+H/9qZVrBcwe+X8ANk8gMAAP//AwBQ SwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMv c2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAFN6kljDAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIA AGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAAAA/wEAAAAEFVGwCHFysAcjwn AJuGLwAAABHwBAAAAAEAAAAAAA3wBAAAAAAADwAPAATwOgUAAAICCvAIAAAAGQQAAAILAACDAAvw SgAAAH8AAADrAb8BAAAQANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0 AG8AUwBoAGEAcABlACAAMgA2AAAAIwAi8awEAACpw6AEAACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l 66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7V mPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYE LfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQ mc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPx alJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA //8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D 0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tb tn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v 3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQA AABkcnMvY29ubmVjdG9yeG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1 UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQDxyB8rwwAAANsAAAAP AAAAZHJzL2Rvd25yZXYueG1sRI9Bi8IwFITvgv8hPMGbpnoQrUZZFhRx8bC6lPX2aJ5tsXkpSdS6 v34jCB6HmfmGWaxaU4sbOV9ZVjAaJiCIc6srLhT8HNeDKQgfkDXWlknBgzyslt3OAlNt7/xNt0Mo RISwT1FBGUKTSunzkgz6oW2Io3e2zmCI0hVSO7xHuKnlOEkm0mDFcaHEhj5Lyi+Hq1Hw+zW7Zo9s T7tsNNud0Bn/d9wo1e+1H3MQgdrwDr/aW61gPIHnl/gD5PIfAAD//wMAUEsBAi0AFAAGAAgAAAAh AP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54 bWxQSwECLQAUAAYACAAAACEA8cgfK8MAAADbAAAADwAAAAAAAAAAAAAAAAChAgAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA+QAAAJEDAAAAAAAAD/AQAAAAeLMdAMvaJwCxth0AN/YwAAAAEfAE AAAAAQAAAA8ABPA1BQAAogwK8AgAAAAaBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAABAAvwAAAAYA vwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMgA3AAAAIwAi 8Z0EAACpw5EEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9U eXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/x I6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhC Ln0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ 5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT 2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACP AQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYw WEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSq UqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyX xnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMA UEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShLLSrO zM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsD BBQABgAIAAAAIQDM5Km0wQAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/RisIwFETfBf8hXMEX WVPFtVqNooLiq64fcG2ubbG5KU209e+NIOzjMDNnmOW6NaV4Uu0KywpGwwgEcWp1wZmCy9/+ZwbC eWSNpWVS8CIH61W3s8RE24ZP9Dz7TAQIuwQV5N5XiZQuzcmgG9qKOHg3Wxv0QdaZ1DU2AW5KOY6i qTRYcFjIsaJdTun9/DAKbsdm8Dtvrgd/iU+T6RaL+GpfSvV77WYBwlPr/8Pf9lErGMfw+RJ+gFy9 AQAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAA LgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAA KQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAzOSptMEAAADbAAAADwAAAAAAAAAA AAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIYDAAAAAAAAD/AQAAAAEl8g AKlvJQDDYC4AA7oqAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAQAA8ABPA5BQAAAgIK8AgAAAAbBAAA AgsAAIMAC/BKAAAAfwAAAOsBvwEAABAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMaAAAAvwMA AAIAQQB1AHQAbwBTAGgAYQBwAGUAIAAyADgAAAAjACLxqwQAAKnDnwQAAKoDAAQAD1BLAwQUAAYA CAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqq B2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/F nRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAG zEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB 0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxK V4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1r AzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0L BilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJH GWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/ loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEA AAA5AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nM S7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAO8bLsLC AAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxET89rwjAUvg/8H8ITdpupHsbsjCKCY1R2sErZbo/m rS02LyWJtvWvN4fBjh/f79VmMK24kfONZQXzWQKCuLS64UrB+bR/eQPhA7LG1jIpGMnDZj15WmGq bc9HuuWhEjGEfYoK6hC6VEpf1mTQz2xHHLlf6wyGCF0ltcM+hptWLpLkVRpsODbU2NGupvKSX42C 78PyWozFF2XFfJn9oDP+fvpQ6nk6bN9BBBrCv/jP/akVLOLY+CX+ALl+AAAA//8DAFBLAQItABQA BgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25uZWN0 b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAO8bLsLCAAAA2wAAAA8AAAAAAAAAAAAAAAAAoQIAAGRy cy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACQAwAAAAAAAA/wEAAAAEgZIQBPcSUAScsnAFBx JQAAABHwBAAAAAEAAAAPAATwPAUAAAICCvAIAAAAHAQAAAILAACDAAvwSgAAAH8AAADrAb8BAAAQ ANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAA MgA5AAAAIwAi8a4EAACpw6IEAACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABb Q29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd 7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbS csg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEV Ll1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBY V/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAA ACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G 1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+ e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIW zOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep 9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9y eG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWq TC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQCAV4tZxQAAANsAAAAPAAAAZHJzL2Rvd25yZXYu eG1sRI9Ba8JAFITvhf6H5RW81U08iEldgxRaiuKhWkK9PbLPJJh9G3ZXjf76riD0OMzMN8y8GEwn zuR8a1lBOk5AEFdWt1wr+Nl9vM5A+ICssbNMCq7koVg8P80x1/bC33TehlpECPscFTQh9LmUvmrI oB/bnjh6B+sMhihdLbXDS4SbTk6SZCoNthwXGuzpvaHquD0ZBb/r7FReyw2tyjRb7dEZf9t9KjV6 GZZvIAIN4T/8aH9pBZMM7l/iD5CLPwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY 1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWe QQAAADkAAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAI AAAAIQCAV4tZxQAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAA AAQABAD5AAAAkwMAAAAAAAAP8BAAAACjsh0AzAwaAEAHLADIByMAAAAR8AQAAAABAAAADwAE8CsF AAAyAArwCAAAAB0EAAACCgAAgwAL8EAAAAB/AAAA7wGAAAAAEQC/AAAABgC/ARAAEAD/AQgAGAA/ AwAACACAwxAAAAC/AwAAAgBPAHYAYQBsACAAMwAwAAAAIwAi8ZsEAACpw48EAACqAwAEAA9QSwME FAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q 5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUK PtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt 1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqw XM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5 lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDB asMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZN C4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCp Yx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgs zzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAA ADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoN cdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQAfCvA0vwAAANsA AAAPAAAAZHJzL2Rvd25yZXYueG1sRE9Ni8IwEL0L+x/CLHjTVIsiXaOIIuhhD1vd+9CMbbGZlGas 9d+bw8IeH+97vR1co3rqQu3ZwGyagCIuvK25NHC9HCcrUEGQLTaeycCLAmw3H6M1ZtY/+Yf6XEoV QzhkaKASaTOtQ1GRwzD1LXHkbr5zKBF2pbYdPmO4a/Q8SZbaYc2xocKW9hUV9/zhDBzKXb7sdSqL 9HY4yeL++31OZ8aMP4fdFyihQf7Ff+6TNZDG9fFL/AF68wYAAP//AwBQSwECLQAUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsB Ai0AFAAGAAgAAAAhAB8K8DS/AAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPUAAACEAwAAAAAAAA/wEAAAAIjzDgAsjDoAbGoXAP1bPwAAABHwBAAAAAEA AAAAAA3wBAAAAAAAEQAPAATwNwUAAKIMCvAIAAAAHgQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAS AL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADMA MQAAACMAIvGfBAAAqcOTBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u 4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhS CvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKl AEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MW zIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHd X2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPL WCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40 YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8 hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYP AAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/I zVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA //8DAFBLAwQUAAYACAAAACEAqZgChsMAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP2WrDMBRE 3wv5B3ELfSmxnLTZnCghLaTkNcsH3FjXC7WujKV4+fuoUMjjMDNnmM2uN5VoqXGlZQWTKAZBnFpd cq7gejmMlyCcR9ZYWSYFAznYbUcvG0y07fhE7dnnIkDYJaig8L5OpHRpQQZdZGvi4GW2MeiDbHKp G+wC3FRyGsdzabDksFBgTd8Fpb/nu1GQHbv32aq7/fjr4vQ5/8JycbODUm+v/X4NwlPvn+H/9lEr +JjA35fwA+T2AQAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAA AAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAA AAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAqZgChsMAAADbAAAA DwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIgDAAAAAAAA D/AQAAAAOQsJAN8ZNgAx7xQALIw6AAAAEfAEAAAAAQAAAAAADfAEAAAAAAASAA8ABPA6BQAAAgIK 8AgAAAAfBAAAQgsAAIMAC/BKAAAAfwAAAOsBvwEAABAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgA gMMaAAAAvwMAAAIAQQB1AHQAbwBTAGgAYQBwAGUAIAAzADIAAAAjACLxrAQAAKnDoAQAAKoDAAQA D1BLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQ x+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykA bXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0w PaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhX jCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE 83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMv LnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9p NguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS1 4YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IR l0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAA ACEAMy8FnkEAAAA5AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQz UFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgA AAAhAGNRd9fDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj09rAjEUxO8Fv0N4Qm/dbC0WWY1S hYL0UvwDenxsnrvBzcuyiZv12zeC0OMwM79hFqvBNqKnzhvHCt6zHARx6bThSsHx8P02A+EDssbG MSm4k4fVcvSywEK7yDvq96ESCcK+QAV1CG0hpS9rsugz1xIn7+I6iyHJrpK6w5jgtpGTPP+UFg2n hRpb2tRUXvc3q8DEX9O3201c/5zOXkcy96kzSr2Oh685iEBD+A8/21ut4GMCjy/pB8jlHwAAAP// AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAAAAAAAAAAAAAAC4CAABk cnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQBjUXfXwwAAANsAAAAPAAAAAAAAAAAA AAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAAkQMAAAAAAAAP8BAAAAD6LhMA K1U1ADMyEwAsjDoAAAAR8AQAAAABAAAADwAE8DUFAACiDArwCAAAACAEAAACCgAAgwAL8EgAAAB/ AAAA7wGAAAAAEwC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAA QgBvAHgAIAAzADMAAAAjACLxnQQAAKnDkQQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADi AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3Y NgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuL er0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6 QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0 kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQA BgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+F XksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSR DNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqj M5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C /Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4 bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapM LVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhADYGOWrBAAAA2wAAAA8AAABkcnMvZG93bnJldi54 bWxEj92KwjAUhO8XfIdwBG8WTf3XahQVVrz15wGOzbEtNieliba+/UYQvBxm5htmuW5MIZ5Uudyy gn4vAkGcWJ1zquBy/uvOQDiPrLGwTApe5GC9av0sMda25iM9Tz4VAcIuRgWZ92UspUsyMuh6tiQO 3s1WBn2QVSp1hXWAm0IOomgiDeYcFjIsaZdRcj89jILbof4dz+vr3l+mx9Fki/n0al9KddrNZgHC U+O/4U/7oBUMh/D+En6AXP0DAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACP AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5 AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQA2Bjlq wQAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAA hgMAAAAAAAAP8BAAAADnMhUAQck1ABgaIQCOOzoAAAAR8AQAAAABAAAAAAAN8AQAAAAAABMADwAE 8DkFAAACAgrwCAAAACEEAABCCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAA AAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADMANAAAACMAIvGrBAAAqcOf BAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht bJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk 8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAm k/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwb SnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6 T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsA AABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWU XvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAs Jb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnv p3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsD BBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0q zszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBL AwQUAAYACAAAACEAg/RKOMIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWsCMRSE74L/ITyh N81aq8jWKCoI0ouohXp8bF53g5uXZZNu1n/fCIUeh5n5hllteluLjlpvHCuYTjIQxIXThksFn9fD eAnCB2SNtWNS8CAPm/VwsMJcu8hn6i6hFAnCPkcFVQhNLqUvKrLoJ64hTt63ay2GJNtS6hZjgtta vmbZQlo0nBYqbGhfUXG//FgFJp5M1xz3cffxdfM6knnMnVHqZdRv30EE6sN/+K991Apmb/D8kn6A XP8CAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAA AAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAA AAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAg/RKOMIAAADbAAAADwAA AAAAAAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAJADAAAAAAAAD/AQ AAAAHrUdAB7JNQCZtx0ASo06AAAAEfAEAAAAAQAAAA8ABPA3BQAAogwK8AgAAAAiBAAAAgoAAIMA C/BIAAAAfwAAAO8BgAAAABQAvwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABl AHgAdAAgAEIAbwB4ACAAMwA1AAAAIwAi8Z8EAACpw5MEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3 irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cV XR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6R gh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsd fo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSRe MaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8D AFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x 2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9 gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6 /2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/p lRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJz L3NoYXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nM yc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQDWowSFwwAAANsAAAAPAAAAZHJzL2Rv d25yZXYueG1sRI/dasJAFITvC77DcgRvim6sjbapq1ShxduoD3DMHpPQ7NmQXfPz9l1B8HKYmW+Y 9bY3lWipcaVlBfNZBII4s7rkXMH59DP9AOE8ssbKMikYyMF2M3pZY6Jtxym1R5+LAGGXoILC+zqR 0mUFGXQzWxMH72obgz7IJpe6wS7ATSXfomgpDZYcFgqsaV9Q9ne8GQXXQ/caf3aXX39epe/LHZar ix2Umoz77y8Qnnr/DD/aB61gEcP9S/gBcvMPAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA 4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA Md1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA My8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAI AAAAIQDWowSFwwAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAA AAQABAD1AAAAiAMAAAAAAAAP8BAAAAAApywACF0nAGuROABVzysAAAAR8AQAAAABAAAAAAAN8AQA AAAAABQADwAE8DwFAAACAgrwCAAAACMEAAACCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEAAAD/ ARgAGAADAwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADMANgAAACMA IvGuBAAAqcOiBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/ 8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaA yVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29N ZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSE rvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jU AAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN /n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe 6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztN QVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4G AAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyy sa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UC AAAA//8DAFBLAwQUAAYACAAAACEAdBGJ9sUAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvC QBSE7wX/w/KE3uomLUiNriKCpVh6qJagt0f2mQSzb8PuaqK/3i0IPQ4z8w0zW/SmERdyvrasIB0l IIgLq2suFfzu1i/vIHxA1thYJgVX8rCYD55mmGnb8Q9dtqEUEcI+QwVVCG0mpS8qMuhHtiWO3tE6 gyFKV0rtsItw08jXJBlLgzXHhQpbWlVUnLZno2D/NTnn1/ybNnk62RzQGX/bfSj1POyXUxCB+vAf frQ/tYK3Mfx9iT9Azu8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAA CwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA FAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAdBGJ 9sUAAADbAAAADwAAAAAAAAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAA AJMDAAAAAAAAD/AQAAAAPAMvAMslJwBY4zcA2vAsAAAAEfAEAAAAAQAAAA8ABPAvBQAAMgAK8AgA AAAkBAAAAgoAAIMAC/BAAAAAfwAAAO8BgAAAABUAvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMQ AAAAvwMAAAIATwB2AGEAbAAgADMANwAAACMAIvGfBAAAqcOTBAAAqgMABAAPUEsDBBQABgAIAAAA IQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6 B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7o DI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsG NHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lp ojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMA AP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9 g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg 63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0 pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/ 9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAA AGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5J zEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAkONoQMMAAADbAAAADwAAAGRy cy9kb3ducmV2LnhtbESPQWvCQBSE70L/w/KE3nSjQVuiq0ilYA8eGtv7I/tMgtm3IfuM8d+7BaHH YWa+YdbbwTWqpy7Ung3Mpgko4sLbmksDP6fPyTuoIMgWG89k4E4BtpuX0Roz62/8TX0upYoQDhka qETaTOtQVOQwTH1LHL2z7xxKlF2pbYe3CHeNnifJUjusOS5U2NJHRcUlvzoD+3KXL3udyiI97w+y uPwev9KZMa/jYbcCJTTIf/jZPlgD6Rv8fYk/QG8eAAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7 /QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAU AAYACAAAACEAkONoQMMAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsF BgAAAAAEAAQA9QAAAIgDAAAAAAAAD/AQAAAA2KczAI3xLAC8HjwAXsExAAAAEfAEAAAAAQAAAAAA DfAEAAAAAAAVAA8ABPAzBQAAogwK8AgAAAAlBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAABYAvwAA AAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAAMwA4AAAA IwAi8ZsEAACpw48EAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVu dF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n 5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91Ky HmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxit xpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvf dVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIA AACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3f vqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy +iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzN LNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD/ /wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShL LSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMA UEsDBBQABgAIAAAAIQA4oqsbvwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRE/LisIwFN0P+A/h Cm4GTR0f1WqUUVDc+viA2+baFpub0kRb/94sBmZ5OO/1tjOVeFHjSssKxqMIBHFmdcm5gtv1MFyA cB5ZY2WZFLzJwXbT+1pjom3LZ3pdfC5CCLsEFRTe14mULivIoBvZmjhwd9sY9AE2udQNtiHcVPIn iubSYMmhocCa9gVlj8vTKLif2u/Zsk2P/hafp/MdlnFq30oN+t3vCoSnzv+L/9wnrWASxoYv4QfI zQcAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAA AC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAA ACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhADiiqxu/AAAA2wAAAA8AAAAAAAAA AAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACEAwAAAAAAAA/wEAAAAA1Z LwA4SBEAvB48AFY0FAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAFgAPAATwOwUAAAICCvAIAAAAJgQA AAILAACDAAvwSgAAAH8AAADrAb8BAAAQANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8D AAACAEEAdQB0AG8AUwBoAGEAcABlACAAMwA5AAAAIwAi8a0EAACpw6EEAACqAwAEAA9QSwMEFAAG AAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4Wpa qgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dP xZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZg BsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8 wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8 SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9 awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZN CwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflS Rxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBF v5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5B AAAAOQAAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/J zEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQAFjh2E xAAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Ba8JAFITvgv9heYXedKMFaaKrFMFSFA/VEurt kX0mwezbsLtq7K/vCoLHYWa+YWaLzjTiQs7XlhWMhgkI4sLqmksFP/vV4B2ED8gaG8uk4EYeFvN+ b4aZtlf+pssulCJC2GeooAqhzaT0RUUG/dC2xNE7WmcwROlKqR1eI9w0cpwkE2mw5rhQYUvLiorT 7mwU/G7Sc37Lt7TOR+n6gM74v/2nUq8v3ccURKAuPMOP9pdW8JbC/Uv8AXL+DwAA//8DAFBLAQIt ABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25u ZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAAWOHYTEAAAA2wAAAA8AAAAAAAAAAAAAAAAAoQIA AGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACSAwAAAAAAAA/wEAAAADhBMAC86A8ASuM3 AK1CGAAAABHwBAAAAAEAAAAPAATwMAUAAKIMCvAIAAAAJwQAAAIKAACDAAvwSAAAAH8AAADvAYAA AAAXAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAg ADQAMAAAACMAIvGYBAAAqcOMBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/e dD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsd KxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H 4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvK v1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJ TGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/ 7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8 T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wX NXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyy sa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UC AAAA//8DAFBLAwQUAAYACAAAACEAntLUYLwAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPSwrC MBDdC94hjOBGNFX8VqOooLj1c4CxGdtiMylNtPX2ZiG4fLz/atOYQrypcrllBcNBBII4sTrnVMHt eujPQTiPrLGwTAo+5GCzbrdWGGtb85neF5+KEMIuRgWZ92UspUsyMugGtiQO3MNWBn2AVSp1hXUI N4UcRdFUGsw5NGRY0j6j5Hl5GQWPU92bLOr70d9m5/F0h/nsbj9KdTvNdgnCU+P/4p/7pBWMw/rw JfwAuf4CAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAA AAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAA AAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCe0tRgvAAAANsAAAAPAAAA AAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAgQMAAAAAAAAP8BAA AACDSDcA8LEhALQvQwA9JCYAAAAR8AQAAAABAAAAAAAN8AQAAAAAABcADwAE8DoFAAACAgrwCAAA ACgEAABCCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAAAAA/AwgACACAwxoA AAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADQAMQAAACMAIvGsBAAAqcOgBAAAqgMABAAPUEsD BBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+ A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57 Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuq ulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWv DcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nb tr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVs c6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pO TA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFST niX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEy YHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQAz LwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjN S85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEA y4Wa3cMAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPT2sCMRTE7wW/Q3hCb92s0hZZjaJCQXop /gE9PjbP3eDmZdnEzfrtm4LQ4zAzv2EWq8E2oqfOG8cKJlkOgrh02nCl4HT8epuB8AFZY+OYFDzI w2o5ellgoV3kPfWHUIkEYV+ggjqEtpDSlzVZ9JlriZN3dZ3FkGRXSd1hTHDbyGmef0qLhtNCjS1t aypvh7tVYOKP6dvdNm6+zxevI5nHhzNKvY6H9RxEoCH8h5/tnVbwPoG/L+kHyOUvAAAA//8DAFBL AQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9j b25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAMuFmt3DAAAA2wAAAA8AAAAAAAAAAAAAAAAA oQIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACRAwAAAAAAAA/wEAAAAEvjNwCjPx0A 6DM4AI3xLAAAABHwBAAAAAEAAAAPAATwLwUAADIACvAIAAAAKQQAAAIKAACDAAvwQAAAAH8AAADv AYAAAAAYAL8AAAAGAL8BEAAQAP8BCAAYAD8DAAAIAIDDEAAAAL8DAAACAE8AdgBhAGwAIAA0ADIA AAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250 ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIK Hmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3 UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBD GK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJ C991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gm bd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGp RzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/Icd vM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAA AP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1R KEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP// AwBQSwMEFAAGAAgAAAAhANiSuKXDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAUhO8F /8PyBG91o6ki0VVEKeihh6b1/sg+k2D2bci+xvjv3UKhx2FmvmE2u8E1qqcu1J4NzKYJKOLC25pL A99f768rUEGQLTaeycCDAuy2o5cNZtbf+ZP6XEoVIRwyNFCJtJnWoajIYZj6ljh6V985lCi7UtsO 7xHuGj1PkqV2WHNcqLClQ0XFLf9xBo7lPl/2OpVFej2eZHG7fJzTmTGT8bBfgxIa5D/81z5ZA29z +P0Sf4DePgEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAA AAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAA AAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhANiSuKXDAAAA2wAAAA8A AAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAAAA/w EAAAABKrMwCOOzoAvR48AJgOPwAAABHwBAAAAAEAAAAAAA3wBAAAAAAAGAAPAATwNQUAAKIMCvAI AAAAKgQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAZAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDD GAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADQAMwAAACMAIvGdBAAAqcORBAAAqgMABAAPUEsD BBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74Lv EOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1 Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTV rdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7a sFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj +ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQ wWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbW TQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlg qWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4 LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEA AAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UK DXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAbgBKF8EAAADb AAAADwAAAGRycy9kb3ducmV2LnhtbESP3YrCMBSE7wXfIRzBG1lT/3e7RlFB8dafBzg2x7bYnJQm 2vr2RhC8HGbmG2a+bEwhHlS53LKCQT8CQZxYnXOq4Hza/vyCcB5ZY2GZFDzJwXLRbs0x1rbmAz2O PhUBwi5GBZn3ZSylSzIy6Pq2JA7e1VYGfZBVKnWFdYCbQg6jaCoN5hwWMixpk1FyO96Nguu+7k3+ 6svOn2eH8XSN+exin0p1O83qH4Snxn/Dn/ZeKxiP4P0l/AC5eAEAAP//AwBQSwECLQAUAAYACAAA ACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQIt ABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1s UEsBAi0AFAAGAAgAAAAhAG4AShfBAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2 LnhtbFBLBQYAAAAABAAEAPUAAACGAwAAAAAAAA/wEAAAAM6aLgAh/DMA/4E6ADVrOAAAABHwBAAA AAEAAAAAAA3wBAAAAAAAGQAPAATwNQUAAKIMCvAIAAAAKwQAAAIKAACDAAvwSAAAAH8AAADvAYAA AAAaAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAg ADQANAAAACMAIvGdBAAAqcORBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/e dD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsd KxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H 4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvK v1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJ TGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/ 7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8 T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wX NXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyy sa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UC AAAA//8DAFBLAwQUAAYACAAAACEA4enSY8EAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP3YrC MBSE7wXfIRzBG9FUqX/VKK7g4q0/D3Bsjm2xOSlN1ta3N8KCl8PMfMOst60pxZNqV1hWMB5FIIhT qwvOFFwvh+EChPPIGkvLpOBFDrabbmeNibYNn+h59pkIEHYJKsi9rxIpXZqTQTeyFXHw7rY26IOs M6lrbALclHISRTNpsOCwkGNF+5zSx/nPKLgfm8F02dx+/XV+imc/WMxv9qVUv9fuViA8tf4b/m8f tYI4hs+X8APk5g0AAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAA AAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAA AAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAOHp0mPBAAAA2wAA AA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACGAwAAAAAA AA/wEAAAAGp5BgAVbkAAYl0SACndRAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAGgAPAATwhgYAAAIA CvAIAAAALAQAAAIKAACTAgvwogEAAAQAAAAAAH8AAADvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAEABAAAAAEEBAAAAAEIBUgIAAEMBEgIAAEQBAgAAAEXB NAAAAEbBEgAAAFHBLgAAAFLBGgAAAFXBAAAAAFbBAAAAAFgBAgAAAH8BGQAZAIABAAAAAIEB//// AIIBAAABAL8BAAAQAMABAAAAAMEBAAABAMQBAAAAAMsBNSUAANEBAQAAANQBAQAAANUBAQAAANYB AgAAAP8BGAAYAAQDAQAAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAA0ADQDw/zgBAADFAU8AUgKe AFIC9QBSAkwBmAEEAjcBCwLWABICFAB5AQoAIgEAAMsA0gAwAPoAAAAGAAgAAgAAQAEgASABIAEg AIAFAAgACAAFBgMAAAAAAJ7BBQAuYAIAigMDAEgSBQDPGAAA488CADZsAgAAAAAABQAIAAQAAAAA AAAAAAAAAAAAAAAAAAAAAABGAHIAZQBlAGYAbwByAG0AIAA0ADUAAAAjACLxoAQAAKnDlAQAAKoD AAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1K xDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbgu KxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G 1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsOD DXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI 83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcw qZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0 nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13ii uVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAh ADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvO T8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAI/9 FxLEAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj0FrwkAUhO8F/8PyhN50E22tjVmllBbam1oR j6/ZZxLNvg27W43/3hWEHoeZ+YbJF51pxImcry0rSIcJCOLC6ppLBZufz8EUhA/IGhvLpOBCHhbz 3kOOmbZnXtFpHUoRIewzVFCF0GZS+qIig35oW+Lo7a0zGKJ0pdQOzxFuGjlKkok0WHNcqLCl94qK 4/rPKMBX+eHGy3a5/X35LtLx7jDd6INSj/3ubQYiUBf+w/f2l1bw9Ay3L/EHyPkVAAD//wMAUEsB Ai0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3No YXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCP/RcSxAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABk cnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiQMAAAAAAAAP8BAAAADiQhAA/Vs/AIAEFgCl f0QAAAAR8AQAAAABAAAADwAE8DcFAACiDArwCAAAAC0EAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAA GwC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0 ADYAAAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/ LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsY Ugr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HS pQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9T FsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxj y1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1O NGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V /IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2 DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGv yM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAA AP//AwBQSwMEFAAGAAgAAAAhAH536Y/DAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj91qwkAU hO+FvsNyCr0R3VjSqNFNsEJLbv15gGP2mASzZ0N2a+Lbu4VCL4eZ+YbZ5qNpxZ1611hWsJhHIIhL qxuuFJxPX7MVCOeRNbaWScGDHOTZy2SLqbYDH+h+9JUIEHYpKqi971IpXVmTQTe3HXHwrrY36IPs K6l7HALctPI9ihJpsOGwUGNH+5rK2/HHKLgWw/RjPVy+/Xl5iJNPbJYX+1Dq7XXcbUB4Gv1/+K9d aAVxAr9fwg+Q2RMAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAA AAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAA AAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAH536Y/DAAAA2wAA AA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAA AA/wEAAAACA+HgC520AAGCIqAJNHRQAAABHwBAAAAAEAAAAAAA3wBAAAAAAAGwAPAATwhgYAAAIA CvAIAAAALgQAAAIKAACTAgvwogEAAAQAAAAAAH8AAADvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIA AIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAEABAAAAAEEBAAAAAEIBUgIAAEMBEgIAAEQBAgAAAEXB NAAAAEbBEgAAAFHBLgAAAFLBGgAAAFXBAAAAAFbBAAAAAFgBAgAAAH8BGQAZAIABAAAAAIEB//// AIIBAAABAL8BAAAQAMABAAAAAMEBAAABAMQBAAAAAMsBNSUAANEBAQAAANQBAQAAANUBAQAAANYB AgAAAP8BGAAYAAQDAQAAAD8DAAAIAIDDGAAAAIgDAAAAAL8DAAACAA0ADQDw/zgBAADFAU8AUgKe AFIC9QBSAkwBmAEEAjcBCwLWABICFAB5AQoAIgEAAMsA0gAwAPoAAAAGAAgAAgAAQAEgASABIAEg AIAFAAgACAC3BwMAAAAAANfEBQCxXgIAOgUDABkPBQDdGAAAIM4CAJFtAgAAAAAABQAIAAQAAAAA AAAAAAAAAAAAAAAAAAAAAABGAHIAZQBlAGYAbwByAG0AIAA0ADcAAAAjACLxoAQAAKnDlAQAAKoD AAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1K xDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbgu KxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G 1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsOD DXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI 83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcw qZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0 nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13ii uVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAh ADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvO T8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhABBj LP7EAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj09rAjEUxO9Cv0N4BW+atRZXV6OUYqG9+Q/x +Nw8d9duXpYk1e23N4LgcZiZ3zCzRWtqcSHnK8sKBv0EBHFudcWFgt32qzcG4QOyxtoyKfgnD4v5 S2eGmbZXXtNlEwoRIewzVFCG0GRS+rwkg75vG+LonawzGKJ0hdQOrxFuavmWJCNpsOK4UGJDnyXl v5s/owAncumGq2a1P6Y/+WB4OI93+qxU97X9mIII1IZn+NH+1greU7h/iT9Azm8AAAD//wMAUEsB Ai0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3No YXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAQYyz+xAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABk cnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiQMAAAAAAAAP8BAAAABBVRsAN18/ABgaIQCm f0QAAAAR8AQAAAABAAAADwAE8DAFAACiDArwCAAAAC8EAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAA HAC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA0 ADgAAAAjACLxmAQAAKnDjAQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/ LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsY Ugr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HS pQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9T FsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxj y1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1O NGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V /IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2 DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGv yM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAA AP//AwBQSwMEFAAGAAgAAAAhAGCk2Ga8AAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxET0sKwjAQ 3QveIYzgRjRV/FajqKC49XOAsRnbYjMpTbT19mYhuHy8/2rTmEK8qXK5ZQXDQQSCOLE651TB7Xro z0E4j6yxsEwKPuRgs263VhhrW/OZ3hefihDCLkYFmfdlLKVLMjLoBrYkDtzDVgZ9gFUqdYV1CDeF HEXRVBrMOTRkWNI+o+R5eRkFj1Pdmyzq+9HfZufxdIf57G4/SnU7zXYJwlPj/+Kf+6QVjMPY8CX8 ALn+AgAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAA AAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAA AAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAYKTYZrwAAADbAAAADwAAAAAA AAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIEDAAAAAAAAD/AQAAAA Kfk1AO9fQQCU40EAyctFAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAcAA8ABPCGBgAAAgAK8AgAAAAw BAAAAgoAAJMCC/CiAQAABAAAAAAAfwAAAO8BgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAA hwAAAAAAiAAAAAAAvwAAAAYAQAEAAAAAQQEAAAAAQgFSAgAAQwESAgAARAECAAAARcE0AAAARsES AAAAUcEuAAAAUsEaAAAAVcEAAAAAVsEAAAAAWAECAAAAfwEZABkAgAEAAAAAgQH///8AggEAAAEA vwEAABAAwAEAAAAAwQEAAAEAxAEAAAAAywE1JQAA0QEBAAAA1AEBAAAA1QEBAAAA1gECAAAA/wEY ABgABAMBAAAAPwMAAAgAgMMYAAAAiAMAAAAAvwMAAAIADQANAPD/OAEAAMUBTwBSAp4AUgL1AFIC TAGYAQQCNwELAtYAEgIUAHkBCgAiAQAAywDSADAA+gAAAAYACAACAABAASABIAEgASAAgAUACAAI ALcHAwAAAAAA18QFALFeAgA6BQMAGQ8FAN0YAAAgzgIAkW0CAAAAAAAFAAgABAAAAAAAAAAAAAAA AAAAAAAAAAAAAEYAcgBlAGUAZgBvAHIAbQAgADQAOQAAACMAIvGgBAAAqcOUBAAAqgMABAAPUEsD BBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74Lv EOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1 Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTV rdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7a sFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj +ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQ wWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbW TQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlg qWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4 LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEA AAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UK DXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEADrAdF8QAAADb AAAADwAAAGRycy9kb3ducmV2LnhtbESPT2sCMRTE70K/Q3gFb5q1Fl1Xo5Riob35D/H43Dx3125e liTV7bc3guBxmJnfMLNFa2pxIecrywoG/QQEcW51xYWC3farl4LwAVljbZkU/JOHxfylM8NM2yuv 6bIJhYgQ9hkqKENoMil9XpJB37cNcfRO1hkMUbpCaofXCDe1fEuSkTRYcVwosaHPkvLfzZ9RgBO5 dMNVs9ofxz/5YHg4pzt9Vqr72n5MQQRqwzP8aH9rBe8TuH+JP0DObwAAAP//AwBQSwECLQAUAAYA CAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBL AQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwu eG1sUEsBAi0AFAAGAAgAAAAhAA6wHRfEAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3du cmV2LnhtbFBLBQYAAAAABAAEAPUAAACJAwAAAAAAAA/wEAAAAAlLNQCZDj8A4A87AAgvRAAAABHw BAAAAAEAAAAPAATwPAUAAAICCvAIAAAAMQQAAAILAACTAAvwUAAAAH8AAADrAb8BAAAQAM4BAgAA ANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAA NQAwAAAAIwAi8agEAACpw5wEAACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABb Q29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd 7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbS csg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEV Ll1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBY V/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAA ACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G 1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+ e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIW zOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep 9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9y eG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWq TC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQDaDsqxvwAAANsAAAAPAAAAZHJzL2Rvd25yZXYu eG1sRE87a8MwEN4L+Q/iAt0aOYaY4EQJbaCQNXaXbhfr/KDWybWutvPvq6HQ8eN7H8+L69VEY+g8 G9huElDElbcdNwY+yveXPaggyBZ7z2TgQQHOp9XTEXPrZ77RVEijYgiHHA20IkOudahachg2fiCO XO1HhxLh2Gg74hzDXa/TJMm0w45jQ4sDXVqqvoofZ4Cz7+GeCr71sq/vS12WxacujXleL68HUEKL /Iv/3FdrYBfXxy/xB+jTLwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcB AAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkA AAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQDa DsqxvwAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5 AAAAjQMAAAAAAAAP8BAAAAC9HjwAdVkvANRsPgAIcC8AAAAR8AQAAAABAAAADwAE8DYFAACiDArw CAAAADIEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAAHQC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACA wxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA1ADEAAAAjACLxngQAAKnDkgQAAKoDAAQAD1BL AwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C 7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW 9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U 1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+ 2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7 o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOk kMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G 1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85 YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QM uCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5B AAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dV Cg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAHRH5ybCAAAA 2wAAAA8AAABkcnMvZG93bnJldi54bWxEj92KwjAUhO8XfIdwBG8WmyrrXzWKK6x4688DnDbHttic lCZr69sbQfBymJlvmNWmM5W4U+NKywpGUQyCOLO65FzB5fw3nINwHlljZZkUPMjBZt37WmGibctH up98LgKEXYIKCu/rREqXFWTQRbYmDt7VNgZ9kE0udYNtgJtKjuN4Kg2WHBYKrGlXUHY7/RsF10P7 PVm06d5fZsef6S+Ws9Q+lBr0u+0ShKfOf8Lv9kErmIzg9SX8ALl+AgAA//8DAFBLAQItABQABgAI AAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54 bWxQSwECLQAUAAYACAAAACEAdEfnJsIAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA9QAAAIcDAAAAAAAAD/AQAAAA4A87AFXPKwB1cUIAp6EuAAAAEfAE AAAAAQAAAAAADfAEAAAAAAAdAA8ABPA3BQAAogwK8AgAAAAzBAAAAgoAAIMAC/BIAAAAfwAAAO8B gAAAAB4AvwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4 ACAANQAyAAAAIwAi8Z8EAACpw5MEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh3 3950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qi ux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQ Dwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgo a8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAA ACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sK W0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDf vb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D 6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XH rBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnht bLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj 5QIAAAD//wMAUEsDBBQABgAIAAAAIQCElXlRwwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/d asJAFITvC77DcoTeFN0o9S+6CbbQktuoD3DMHpNg9mzIriZ5+26h0MthZr5hDulgGvGkztWWFSzm EQjiwuqaSwWX89dsC8J5ZI2NZVIwkoM0mbwcMNa255yeJ1+KAGEXo4LK+zaW0hUVGXRz2xIH72Y7 gz7IrpS6wz7ATSOXUbSWBmsOCxW29FlRcT89jIJb1r+tdv312182+fv6A+vN1Y5KvU6H4x6Ep8H/ h//amVawWsLvl/ADZPIDAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCElXlRwwAA ANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiAMA AAAAAAAP8BAAAADUbD4AqyAuAGnORQA39jAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAB4ADwAE8D4F AAACAgrwCAAAADQEAAACCwAAkwAL8FAAAAB/AAAA6wG/AQAAEADOAQIAAADRAQEAAAD/ARgAGAAD AwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADUAMwAAACMAIvGqBAAA qcOeBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tp FDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBP upAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vR UhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYR L7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEA AAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVX snWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC 6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03g ZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMA UEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEo Sy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8D AFBLAwQUAAYACAAAACEAKtxUxsEAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPT2vCQBTE7wW/ w/KE3upGS0Wiq6ggeG3Si7dn9uUPZt/G7FPjt3cLhR6HmfkNs9oMrlV36kPj2cB0koAiLrxtuDLw kx8+FqCCIFtsPZOBJwXYrEdvK0ytf/A33TOpVIRwSNFALdKlWoeiJodh4jvi6JW+dyhR9pW2PT4i 3LV6liRz7bDhuFBjR/uaikt2cwZ4fu3OM8FdK4vyPJR5np10bsz7eNguQQkN8h/+ax+tga9P+P0S f4BevwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAA AAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAAAAAAAAA AAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQAq3FTGwQAAANsAAAAP AAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAAjwMAAAAAAAAP 8BAAAAAk8iEA5lozADtAJAB5cTMAAAAR8AQAAAABAAAADwAE8DYFAACiDArwCAAAADUEAAACCgAA gwAL8EgAAAB/AAAA7wGAAAAAHwC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBU AGUAeAB0ACAAQgBvAHgAIAA1ADQAAAAjACLxngQAAKnDkgQAAKoDAAQAD1BLAwQUAAYACAAAACEA 8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpuger RxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO 3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1 Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1 JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD/ /wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPR vXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8 WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZt tzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au /+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABk cnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxL SczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAGQwRL7CAAAA2wAAAA8AAABkcnMv ZG93bnJldi54bWxEj92KwjAUhO8F3yEcYW/Epop/2zWKLqx4W/UBTptjW2xOShNtffuNsLCXw8x8 w2x2vanFk1pXWVYwjWIQxLnVFRcKrpefyRqE88gaa8uk4EUOdtvhYIOJth2n9Dz7QgQIuwQVlN43 iZQuL8mgi2xDHLybbQ36INtC6ha7ADe1nMXxUhqsOCyU2NB3Sfn9/DAKbqduvPjssqO/rtL58oDV KrMvpT5G/f4LhKfe/4f/2ietYDGH95fwA+T2FwAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh ADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYA CAAAACEAZDBEvsIAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA AAAEAAQA9QAAAIcDAAAAAAAAD/AQAAAAO0AkABsiMgCWnisAbfQ0AAAAEfAEAAAAAQAAAAAADfAE AAAAAAAfAA8ABPA9BQAAAgIK8AgAAAA2BAAAAgsAAJMAC/BQAAAAfwAAAOsBvwEAABAAzgECAAAA 0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMaAAAAvwMAAAIAQQB1AHQAbwBTAGgAYQBwAGUAIAA1 ADUAAAAjACLxqQQAAKnDnQQAAKoDAAQAD1BLAwQUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6sHtWY9QEITFtiOxAG6+7bO93u Xoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDTozBgQt90By01xe1Nt9BBLsRtJy yDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRTt9CZzzGLxx1fryQJRpLiYRUu XVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8A/FqUn42E2Mol2jZAMHmkFhX /p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4BAAD//wMAUEsDBBQABgAIAAAA IQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC/4PR3vMlQyklvmyFrCGFrsbW fZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw8H56e3oBo8VT9DMTOriiwr57 fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewHtNu2fbbymwHdimkO0YEc4hbM 6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uBve/d/NMbmAhDYfmojpX8J6n2 7wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAGRycy9jb25uZWN0b3J4 bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapM LVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAMp5aSnAAAAA2wAAAA8AAABkcnMvZG93bnJldi54 bWxEj82KwkAQhO8LvsPQgrd1oqBIdBQVFrya7GVvbabzg5memOnV+PaOsLDHoqq+oja7wbXqTn1o PBuYTRNQxIW3DVcGvvOvzxWoIMgWW89k4EkBdtvRxwZT6x98pnsmlYoQDikaqEW6VOtQ1OQwTH1H HL3S9w4lyr7StsdHhLtWz5NkqR02HBdq7OhYU3HNfp0BXt66y1zw0MqqvAxlnmc/OjdmMh72a1BC g/yH/9ona2CxgPeX+AP09gUAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcB AAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkA AAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQDK eWkpwAAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5 AAAAjgMAAAAAAAAP8BAAAAAYGiEAV64XAC9oIwDqxBcAAAAR8AQAAAABAAAADwAE8DgFAACiDArw CAAAADcEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAAIAC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACA wxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA1ADYAAAAjACLxoAQAAKnDlAQAAKoDAAQAD1BL AwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C 7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW 9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U 1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+ 2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7 o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOk kMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G 1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85 YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QM uCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5B AAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dV Cg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAPuuf1LEAAAA 2wAAAA8AAABkcnMvZG93bnJldi54bWxEj9Fqg0AURN8D/YflFvoS6poSTWuzShpI8TVpPuDq3qjU vSvuNpq/zxYKfRxm5gyzLWbTiyuNrrOsYBXFIIhrqztuFJy/Ds+vIJxH1thbJgU3clDkD4stZtpO fKTryTciQNhlqKD1fsikdHVLBl1kB+LgXexo0Ac5NlKPOAW46eVLHKfSYMdhocWB9i3V36cfo+BS Tsvkbao+/XlzXKcf2G0qe1Pq6XHevYPwNPv/8F+71AqSFH6/hB8g8zsAAAD//wMAUEsBAi0AFAAG AAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQD7rn9SxAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiQMAAAAAAAAP8BAAAAAwaCMAjXUWAIvGKgDfRxkAAAAR 8AQAAAABAAAAAAAN8AQAAAAAACAADwAE8D4FAAACAgrwCAAAADgEAAACCwAAkwAL8FAAAAB/AAAA 6wG/AQAAEADOAQIAAADRAQEAAAD/ARgAGAADAwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABv AFMAaABhAHAAZQAgADUANwAAACMAIvGqBAAAqcOeBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+Jeul AAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1 AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33 QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnP MYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpS fjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP// AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He 8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7 egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9 tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G97938 0xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAA ZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBS KC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAVedSxcEAAADbAAAADwAA AGRycy9kb3ducmV2LnhtbESPT2vCQBTE7wW/w/KE3upGoSrRVbQgeG3ixdsz+/IHs29j9lXjt3cL hR6HmfkNs94OrlV36kPj2cB0koAiLrxtuDJwyg8fS1BBkC22nsnAkwJsN6O3NabWP/ib7plUKkI4 pGigFulSrUNRk8Mw8R1x9ErfO5Qo+0rbHh8R7lo9S5K5dthwXKixo6+aimv24wzw/NZdZoL7Vpbl ZSjzPDvr3Jj38bBbgRIa5D/81z5aA58L+P0Sf4DevAAAAP//AwBQSwECLQAUAAYACAAAACEA/iXr pQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQAzLwWeQQAAADkAAAAUAAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBL AQItABQABgAIAAAAIQBV51LFwQAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD5AAAAjwMAAAAAAAAP8BAAAACgQjQAEqENALeQNgCltw0AAAAR8AQAAAAB AAAADwAE8DAFAACiDArwCAAAADkEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAAIQC/AAAABgC/ARAA EAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA1ADgAAAAjACLxmAQA AKnDjAQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfb aRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCX L52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyP luLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5f fCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAAL AAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm87 6hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgY S0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc 996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwME FAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NV MtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAG AAgAAAAhAOV9Tru8AAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxET0sKwjAQ3QveIYzgRjRV/Faj qKC49XOAsRnbYjMpTbT19mYhuHy8/2rTmEK8qXK5ZQXDQQSCOLE651TB7Xroz0E4j6yxsEwKPuRg s263VhhrW/OZ3hefihDCLkYFmfdlLKVLMjLoBrYkDtzDVgZ9gFUqdYV1CDeFHEXRVBrMOTRkWNI+ o+R5eRkFj1Pdmyzq+9HfZufxdIf57G4/SnU7zXYJwlPj/+Kf+6QVTMLY8CX8ALn+AgAA//8DAFBL AQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9z aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA5X1Ou7wAAADbAAAADwAAAAAAAAAAAAAAAACYAgAA ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIEDAAAAAAAAD/AQAAAAzfsKAKW3DQBiXRIA 94kQAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAhAA8ABPA+BQAAAgIK8AgAAAA6BAAAAgsAAJMAC/BQ AAAAfwAAAOsBvwEAABAAzgECAAAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMaAAAAvwMAAAIA QQB1AHQAbwBTAGgAYQBwAGUAIAA1ADkAAAAjACLxqgQAAKnDngQAAKoDAAQAD1BLAwQUAAYACAAA ACEA/iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM 6R6sHtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSU DTozBgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVe MmRTt9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffC T5O8A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4ef ar4BAAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEM hvdC/4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilw nGhw8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz2 4ewHtNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJL U8uBve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5 AAAAFAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dV Cg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAEs0YyzBAAAA 2wAAAA8AAABkcnMvZG93bnJldi54bWxEj09rwkAUxO8Fv8PyhN7qRkHR6Cq2UPBq4sXbM/vyB7Nv Y/ZV02/vFgoeh5n5DbPZDa5Vd+pD49nAdJKAIi68bbgycMq/P5aggiBbbD2TgV8KsNuO3jaYWv/g I90zqVSEcEjRQC3SpVqHoiaHYeI74uiVvncoUfaVtj0+Ity1epYkC+2w4bhQY0dfNRXX7McZ4MWt u8wEP1tZlpehzPPsrHNj3sfDfg1KaJBX+L99sAbmK/j7En+A3j4BAAD//wMAUEsBAi0AFAAGAAgA AAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAxAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAuAgAAZHJzL2Nvbm5lY3Rvcnht bC54bWxQSwECLQAUAAYACAAAACEASzRjLMEAAADbAAAADwAAAAAAAAAAAAAAAAChAgAAZHJzL2Rv d25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAI8DAAAAAAAAD/AQAAAA0fQ7AKqAGgDoQj4APZcaAAAA EfAEAAAAAQAAAA8ABPAzBQAAogwK8AgAAAA7BAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAACIAvwAA AAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANgAwAAAA IwAi8ZsEAACpw48EAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVu dF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n 5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91Ky HmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxit xpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvf dVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIA AACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3f vqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy +iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzN LNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD/ /wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShL LSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMA UEsDBBQABgAIAAAAIQDVZ4gAvwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRE/LisIwFN0PzD+E OzCbwaYOY9VqFBVG3Fb9gGtz+8DmpjTR1r83C8Hl4byX68E04k6dqy0rGEcxCOLc6ppLBefT/2gG wnlkjY1lUvAgB+vV58cSU217zuh+9KUIIexSVFB536ZSurwigy6yLXHgCtsZ9AF2pdQd9iHcNPI3 jhNpsObQUGFLu4ry6/FmFBSH/mcy7y97f55mf8kW6+nFPpT6/ho2CxCeBv8Wv9wHrSAJ68OX8APk 6gkAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAA AC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAA ACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhANVniAC/AAAA2wAAAA8AAAAAAAAA AAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACEAwAAAAAAAA/wEAAAAOlC PgDfRxkAfqRFADEaHAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAIgAPAATwLwUAADIACvAIAAAAPAQA AAIKAACDAAvwQAAAAH8AAADvAYAAAAAjAL8AAAAGAL8BEAAQAP8BCAAYAD8DAAAIAIDDEAAAAL8D AAACAE8AdgBhAGwAIAA2ADEAAAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeK u/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVd H2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGC HTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+ jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4x pmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMA UEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHa QxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2A koLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mV ERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMv c2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJ z0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAGP1erLDAAAA2wAAAA8AAABkcnMvZG93 bnJldi54bWxEj0FrwkAUhO8F/8PyhN7qJg2GEl1FlII99GDa3h/ZZxLMvg3Z1xj/vVsoeBxm5htm vZ1cp0YaQuvZQLpIQBFX3rZcG/j+en95AxUE2WLnmQzcKMB2M3taY2H9lU80llKrCOFQoIFGpC+0 DlVDDsPC98TRO/vBoUQ51NoOeI1w1+nXJMm1w5bjQoM97RuqLuWvM3Cod2U+6kyW2flwlOXl5/Mj S415nk+7FSihSR7h//bRGshT+PsSf4De3AEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADi AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAz LwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgA AAAhAGP1erLDAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA BAAEAPUAAACIAwAAAAAAAA/wEAAAAOzeDwBzPxgALawWAMCxHAAAABHwBAAAAAEAAAAAAA3wBAAA AAAAIwAPAATwNQUAAKIMCvAIAAAAPQQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAkAL8AAAAGAL8B EAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADYAMgAAACMAIvGd BAAAqcORBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOp V9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59 IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXs zI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lG fl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEA AAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhG bzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKi GBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy 0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBL AwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszP s1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQU AAYACAAAACEASvmz7MEAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP0YrCMBRE3wX/IVzBF1lT xa1ajaKC4quuH3Btrm2xuSlNtPXvjSDs4zAzZ5jlujWleFLtCssKRsMIBHFqdcGZgsvf/mcGwnlk jaVlUvAiB+tVt7PERNuGT/Q8+0wECLsEFeTeV4mULs3JoBvaijh4N1sb9EHWmdQ1NgFuSjmOolga LDgs5FjRLqf0fn4YBbdjM/idN9eDv0xPk3iLxfRqX0r1e+1mAcJT6//D3/ZRK4jH8PkSfoBcvQEA AP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4B AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkC AABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAEr5s+zBAAAA2wAAAA8AAAAAAAAAAAAA AAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACGAwAAAAAAAA/wEAAAAP+BOgAI NxcAlONBAJQMGgAAABHwBAAAAAEAAAAAAA3wBAAAAAAAJAAPAATwNgUAAKIMCvAIAAAAPgQAAAIK AACDAAvwSAAAAH8AAADvAYAAAAAlAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAAC AFQAZQB4AHQAIABCAG8AeAAgADYAMwAAACMAIvGeBAAAqcOSBAAAqgMABAAPUEsDBBQABgAIAAAA IQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6 B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7o DI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsG NHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lp ojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMA AP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9 g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg 63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0 pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/ 9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAA AGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5J zEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAJbUWd8IAAADbAAAADwAAAGRy cy9kb3ducmV2LnhtbESP3YrCMBSE7xd8h3AEbxZN/au7XaOooHjrzwMcm2NbtjkpTbT17Y0geDnM zDfMfNmaUtypdoVlBcNBBII4tbrgTMH5tO3/gHAeWWNpmRQ8yMFy0fmaY6Jtwwe6H30mAoRdggpy 76tESpfmZNANbEUcvKutDfog60zqGpsAN6UcRVEsDRYcFnKsaJNT+n+8GQXXffM9/W0uO3+eHSbx GovZxT6U6nXb1R8IT63/hN/tvVYQj+H1JfwAuXgCAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9 AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQA BgAIAAAAIQAltRZ3wgAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUG AAAAAAQABAD1AAAAhwMAAAAAAAAP8BAAAABqIDMArdkJAP+BOgBysgwAAAAR8AQAAAABAAAAAAAN 8AQAAAAAACUADwAE8DoFAAACAgrwCAAAAD8EAABCCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEA AAD/ARgAGAADAwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADYANAAA ACMAIvGsBAAAqcOgBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGvi Eeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4r RXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoY R29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSg TlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYF M1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNk JHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x 9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5 DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1 zu4GAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54 bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK3 4+UCAAAA//8DAFBLAwQUAAYACAAAACEAkEdlJcMAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP wWrDMBBE74X8g9hAb7Wc0ITiRjGJoRB6CUkL7XGxNraItTKWajl/XxUKOQ4z84bZlJPtxEiDN44V LLIcBHHttOFGwefH29MLCB+QNXaOScGNPJTb2cMGC+0in2g8h0YkCPsCFbQh9IWUvm7Jos9cT5y8 ixsshiSHRuoBY4LbTi7zfC0tGk4LLfZUtVRfzz9WgYlHM/aHKu7fv769jmRuK2eUepxPu1cQgaZw D/+3D1rB+hn+vqQfILe/AAAA//8DAFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAA AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEA AAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAA ABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAJBH ZSXDAAAA2wAAAA8AAAAAAAAAAAAAAAAAoQIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkA AACRAwAAAAAAAA/wEAAAAKdFEwDYHA8A0O0UAIM/GAAAABHwBAAAAAEAAAAPAATwPwUAAAICCvAI AAAAQAQAAEILAACTAAvwUAAAAH8AAADrAb8BAAAQAM4BAgAAANEBAQAAAP8BGAAYAAMDAAAAAD8D CAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAANgA1AAAAIwAi8asEAACpw58EAACq AwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHN TsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8 LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6 FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40 NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdK XPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9y ZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv 2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qr YcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9q I3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAG AAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLKxr8jNUShLLSrOzM+z VTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQA BgAIAAAAIQAKL6HYwgAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Li8JAEITvgv9haMGbTjao u2SdiCzIevWB5NhkevPYTE/IjCb+e0cQPBZV9RW13gymETfqXGVZwcc8AkGcW11xoeB82s2+QDiP rLGxTAru5GCTjkdrTLTt+UC3oy9EgLBLUEHpfZtI6fKSDLq5bYmD92c7gz7IrpC6wz7ATSPjKFpJ gxWHhRJb+ikp/z9ejYLL9TOLY9Nu6/x3p+t4yHq3XCg1nQzbbxCeBv8Ov9p7rWC1hOeX8ANk+gAA AP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAAAAAAAAAAAAAADEB AABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAAAAAAAAAAAAAAC4C AABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQAKL6HYwgAAANsAAAAPAAAAAAAA AAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAAkAMAAAAAAAAP8BAAAABy pRAA2BwPANDtFADFmhAAAAAR8AQAAAABAAAADwAE8DYFAACiDArwCAAAAEEEAAACCgAAgwAL8EgA AAB/AAAA7wGAAAAAJgC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0 ACAAQgBvAHgAIAA2ADYAAAAjACLxngQAAKnDkgQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0A AADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BI pm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGs msuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8 bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmec MoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsD BBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmj Tm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR 4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3 YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9 V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hh cGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1 VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhADXCte/CAAAA2wAAAA8AAABkcnMvZG93bnJl di54bWxEj92KwjAUhO8F3yGcBW/Epspa3a5RVkHx1p8HOG2ObdnmpDRZW9/eLAheDjPzDbPa9KYW d2pdZVnBNIpBEOdWV1wouF72kyUI55E11pZJwYMcbNbDwQpTbTs+0f3sCxEg7FJUUHrfpFK6vCSD LrINcfButjXog2wLqVvsAtzUchbHiTRYcVgosaFdSfnv+c8ouB278fyryw7+ujh9JlusFpl9KDX6 6H++QXjq/Tv8ah+1giSB/y/hB8j1EwAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HS AAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5B AAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA NcK178IAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA 9QAAAIcDAAAAAAAAD/AQAAAATeEIAIgCEADiQhAA2tQSAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAm AA8ABPA2BQAAogwK8AgAAABCBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAACcAvwAAAAYAvwEQABAA /wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANgA3AAAAIwAi8Z4EAACp w5IEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10u eG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kU M0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+d jxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi 2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wn qHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAA AF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX +j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJ n1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3Pfe vqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQA BgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLU M1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAI AAAAIQBajhB0wgAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/disIwFITvBd8hHGFvRFPFbbUa RRdWvPXnAY7NsS02J6WJtr79RhD2cpiZb5jVpjOVeFLjSssKJuMIBHFmdcm5gsv5dzQH4Tyyxsoy KXiRg82631thqm3LR3qefC4ChF2KCgrv61RKlxVk0I1tTRy8m20M+iCbXOoG2wA3lZxGUSwNlhwW Cqzpp6DsfnoYBbdDO/xetNe9vyTHWbzDMrnal1Jfg267BOGp8//hT/ugFcQJvL+EHyDXfwAAAP// AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABk cnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAFqOEHTCAAAA2wAAAA8AAAAAAAAAAAAAAAAA mAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACHAwAAAAAAAA/wEAAAAHkONwA9LgwA 1Gw+AMkDDwAAABHwBAAAAAEAAAAAAA3wBAAAAAAAJwAPAATwMwUAAKIMCvAIAAAAQwQAAAIKAACD AAvwSAAAAH8AAADvAYAAAAAoAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQA ZQB4AHQAIABCAG8AeAAgADYAOAAAACMAIvGbBAAAqcOPBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tH FV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7e kYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVL HX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUk XjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP// AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9 cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xY fYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23 Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/ 6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRy cy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJ zMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAKxGEBr8AAADbAAAADwAAAGRycy9k b3ducmV2LnhtbERPy4rCMBTdD8w/hDswm8GmDmPVahQVRtxW/YBrc/vA5qY00da/NwvB5eG8l+vB NOJOnastKxhHMQji3OqaSwXn0/9oBsJ5ZI2NZVLwIAfr1efHElNte87ofvSlCCHsUlRQed+mUrq8 IoMusi1x4ArbGfQBdqXUHfYh3DTyN44TabDm0FBhS7uK8uvxZhQUh/5nMu8ve3+eZn/JFuvpxT6U +v4aNgsQngb/Fr/cB60gCWPDl/AD5OoJAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEA ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1f YdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8F nkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAA IQArEYQGvwAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQA BAD1AAAAhAMAAAAAAAAP8BAAAACJ6wUAU9skAORJDQClrScAAAAR8AQAAAABAAAAAAAN8AQAAAAA ACgADwAE8D4FAAACAgrwCAAAAEQEAABCCwAAkwAL8FAAAAB/AAAA6wG/AQAAEADOAQIAAADRAQEA AAD/ARgAGAADAwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADYAOQAA ACMAIvGqBAAAqcOeBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGvi Eeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4r RXaAyVAZIiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoY R29NZlI1o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSg TlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYF M1jUAAAAlwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNk JHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x 9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5 DztNQVi5L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1 zu4GAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54 bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK3 4+UCAAAA//8DAFBLAwQUAAYACAAAACEAi2Kr3cEAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP zarCMBSE94LvEI7gTlOLv9UoIohu9V7E5aE5ttXmpDTR1rc3woW7HGbmG2a1aU0pXlS7wrKC0TAC QZxaXXCm4PdnP5iDcB5ZY2mZFLzJwWbd7aww0bbhE73OPhMBwi5BBbn3VSKlS3My6Ia2Ig7ezdYG fZB1JnWNTYCbUsZRNJUGCw4LOVa0yyl9nJ9GweU5u8axqbb39LDX97i9Nm4yVqrfa7dLEJ5a/x/+ ax+1gukCvl/CD5DrDwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAAL AAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAU AAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQCLYqvd wQAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAA jwMAAAAAAAAP8BAAAAAHnQsAfEQmAOzeDwDFvScAAAAR8AQAAAABAAAADwAE8DMFAACiDArwCAAA AEUEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAAKQC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgA AAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA3ADAAAAAjACLxmwQAAKnDjwQAAKoDAAQAD1BLAwQU AAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDm Km2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+ 1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U 3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBc zhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mU Lvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFq wzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0L iqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKlj HnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzP MNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAA OQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x 07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAFC+Ht2/AAAA2wAA AA8AAABkcnMvZG93bnJldi54bWxET8uKwjAU3Q/4D+EKbgabKjNWq1F0YMRt1Q+4NrcPbG5KE239 +8lCmOXhvDe7wTTiSZ2rLSuYRTEI4tzqmksF18vvdAnCeWSNjWVS8CIHu+3oY4Optj1n9Dz7UoQQ dikqqLxvUyldXpFBF9mWOHCF7Qz6ALtS6g77EG4aOY/jhTRYc2iosKWfivL7+WEUFKf+83vV347+ mmRfiwPWyc2+lJqMh/0ahKfB/4vf7pNWkIT14Uv4AXL7BwAA//8DAFBLAQItABQABgAIAAAAIQDw 94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwEC LQAUAAYACAAAACEAUL4e3b8AAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1s UEsFBgAAAAAEAAQA9QAAAIQDAAAAAAAAD/AQAAAA0M0DADYmJwBlLwsAiPgpAAAAEfAEAAAAAQAA AAAADfAEAAAAAAApAA8ABPA3BQAAogwK8AgAAABGBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAACoA vwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwAx AAAAIwAi8Z8EAACpw5MEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29u dGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7i Ch5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK 91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUA QxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbM iQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1f YdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tY Jm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRh qUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyH HbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8A AAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jN UShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD/ /wMAUEsDBBQABgAIAAAAIQA/8rtGwwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/RasJAFETf hf7Dcgt9kbpRrGlTN0ELSl61fsA1e01Cs3dDdjXJ37uC0MdhZs4w62wwjbhR52rLCuazCARxYXXN pYLT7+79E4TzyBoby6RgJAdZ+jJZY6Jtzwe6HX0pAoRdggoq79tESldUZNDNbEscvIvtDPogu1Lq DvsAN41cRNFKGqw5LFTY0k9Fxd/xahRc8n768dWf9/4UH5arLdbx2Y5Kvb0Om28Qngb/H362c60g nsPjS/gBMr0DAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAA AAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAA AAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQA/8rtGwwAAANsAAAAP AAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiAMAAAAAAAAP 8BAAAAAruwUAY6UZAIYZDQC1dxwAAAAR8AQAAAABAAAAAAAN8AQAAAAAACoADwAE8D8FAAACAgrw CAAAAEcEAABCCwAAkwAL8FAAAAB/AAAA6wG/AQAAEADOAQIAAADRAQEAAAD/ARgAGAADAwAAAAA/ AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADcAMgAAACMAIvGrBAAAqcOfBAAA qgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1 vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mY ehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYe NDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3Dn Slz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABf cmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8 L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9a q2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CP aiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQA BgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszP s1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQU AAYACAAAACEAAB+vccIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPT4vCMBTE78J+h/AW9qap YbXSNYosyHr1D+Lx0bxtq81LaaKt394IgsdhZn7DzJe9rcWNWl851jAeJSCIc2cqLjQc9uvhDIQP yAZrx6ThTh6Wi4/BHDPjOt7SbRcKESHsM9RQhtBkUvq8JIt+5Bri6P271mKIsi2kabGLcFtLlSRT abHiuFBiQ78l5Zfd1Wo4XtOTUrZZnfO/tTmr/tT5ybfWX5/96gdEoD68w6/2xmhIFTy/xB8gFw8A AAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAx AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAu AgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAAB+vccIAAADbAAAADwAAAAAA AAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAJADAAAAAAAAD/AQAAAA qWwLAIwOGwCOrg8A1YccAAAAEfAEAAAAAQAAAA8ABPA4BQAAogwK8AgAAABIBAAAAgoAAIMAC/BI AAAAfwAAAO8BgAAAACsAvwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgA dAAgAEIAbwB4ACAANwAzAAAAIwAi8aAEAACpw5QEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9 AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9g SKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0x rJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5J PG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZn nDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBL AwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZ o05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC 0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZA t2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRET fVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3No YXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9L tVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQCgbICqxAAAANsAAAAPAAAAZHJzL2Rvd25y ZXYueG1sRI/dasJAFITvhb7Dcgq9kbqxtkaja2iFltzG+gDH7DEJZs+G7Jqft+8WCr0cZuYbZp+O phE9da62rGC5iEAQF1bXXCo4f38+b0A4j6yxsUwKJnKQHh5me0y0HTin/uRLESDsElRQed8mUrqi IoNuYVvi4F1tZ9AH2ZVSdzgEuGnkSxStpcGaw0KFLR0rKm6nu1FwzYb523a4fPlznL+uP7COL3ZS 6ulxfN+B8DT6//BfO9MK4hX8fgk/QB5+AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHd X2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMv BZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAA ACEAoGyAqsQAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAE AAQA9QAAAIkDAAAAAAAAD/AQAAAAcp0DAEbwGwDN+woAmMIeAAAAEfAEAAAAAQAAAAAADfAEAAAA AAArAA8ABPA3BQAAogwK8AgAAABJBAAAAgoAAIMAC/BIAAAAfwAAAO8BgAAAACwAvwAAAAYAvwEQ ABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgAdAAgAEIAbwB4ACAANwA0AAAAIwAi8Z8E AACpw5MEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAABbQ29udGVudF9UeXBl c10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9gSKZt2DYJmVh33950Py7iCh5n5v/xI6lX 22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0xrJrLi3q9C8Qiux0rGFIK91KyHmhCLn0g ly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5JPG7z+kASaWQQDwfh0qUAQxitxpRJ5ezM j5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZnnDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+ X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBLAwQUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZo05vhV5LB7sKW0lMY8tYJm3fvqYwWEZv O+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIY GEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZAt2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ 3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRETfVf+QvxMq/XHrBc1dg8AAAD//wMAUEsD BBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3NoYXBleG1sLnhtbLKxr8jNUShLLSrOzM+z VTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQA BgAIAAAAIQAvhRjewwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/dasJAFITvhb7Dcgq9Ed1Y UqPRTbBCS279eYBj9pgEs2dDdmvi27uFQi+HmfmG2eajacWdetdYVrCYRyCIS6sbrhScT1+zFQjn kTW2lknBgxzk2ctki6m2Ax/ofvSVCBB2KSqove9SKV1Zk0E3tx1x8K62N+iD7CupexwC3LTyPYqW 0mDDYaHGjvY1lbfjj1FwLYbpx3q4fPtzcoiXn9gkF/tQ6u113G1AeBr9f/ivXWgFSQy/X8IPkNkT AAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAu AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAAp AgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAvhRjewwAAANsAAAAPAAAAAAAAAAAA AAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiAMAAAAAAAAP8BAAAABz2QQA 0ccxAAg7DAAjmjQAAAAR8AQAAAABAAAAAAAN8AQAAAAAACwADwAE8EAFAAACAgrwCAAAAEoEAABC CwAAkwAL8FAAAAB/AAAA6wG/AQAAEADOAQIAAADRAQEAAAD/ARgAGAADAwAAAAA/AwgACACAwxoA AAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADcANQAAACMAIvGsBAAAqcOgBAAAqgMABAAPUEsD BBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzU7EIBDH7ya+ A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1vC4rKQBtcB57 Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mYehWN/TA9qJuq ulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYeNDT4SFeMIdWv DcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3DnSlz4wgTzf/Nb tr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABfcmVscy8ucmVs c6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8L9rtL2k2C4pO TA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9aq2HE5LXhjFST niX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CPaiN/0hGXSvEy YHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQABgAIAAAAIQAz LwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjN S85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEA j/Y3BcMAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvCQBSE7wX/w/IK3uqmoWlKdBURQr02 FfH4yL4m0ezbkF2T+O/dguBxmJlvmNVmMq0YqHeNZQXviwgEcWl1w5WCw2/+9gXCeWSNrWVScCMH m/XsZYWZtiP/0FD4SgQIuwwV1N53mZSurMmgW9iOOHh/tjfog+wrqXscA9y0Mo6iT2mw4bBQY0e7 mspLcTUKjtf0FMem257L71yf4+k0uuRDqfnrtF2C8DT5Z/jR3msFaQL/X8IPkOs7AAAA//8DAFBL AQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9j b25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAI/2NwXDAAAA2wAAAA8AAAAAAAAAAAAAAAAA oQIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACRAwAAAAAAAA/wEAAAACqOCgD6MDMA 1swOAEOqNAAAABHwBAAAAAEAAAAPAATwNgUAAKIMCvAIAAAASwQAAAIKAACDAAvwSAAAAH8AAADv AYAAAAAtAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8A eAAgADcANgAAACMAIvGeBAAAqcOSBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlY d9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvE IrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlk EA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8Y KGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgA AAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7 CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg 372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9u A+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1 x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54 bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK3 4+UCAAAA//8DAFBLAwQUAAYACAAAACEAsBsjMsIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP 3YrCMBSE7wXfIRxhb0RTxW21GkUXVrz15wGOzbEtNieliba+/UYQ9nKYmW+Y1aYzlXhS40rLCibj CARxZnXJuYLL+Xc0B+E8ssbKMil4kYPNut9bYapty0d6nnwuAoRdigoK7+tUSpcVZNCNbU0cvJtt DPogm1zqBtsAN5WcRlEsDZYcFgqs6aeg7H56GAW3Qzv8XrTXvb8kx1m8wzK52pdSX4NuuwThqfP/ 4U/7oBUkMby/hB8g138AAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCwGyMywgAA ANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhwMA AAAAAAAP8BAAAADzvgIAtBI0AE4dCgAG5TYAAAAR8AQAAAABAAAAAAAN8AQAAAAAAC0ADwAE8DYF AACiDArwCAAAAEwEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAALgC/AAAABgC/ARAAEAD/AQAAGAA/ AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA3ADcAAAAjACLxngQAAKnDkgQAAKoD AAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1K xDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbgu KxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G 1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsOD DXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI 83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcw qZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0 nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13ii uVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAh ADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvO T8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAN9X hqnCAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj92KwjAUhO8F3yGcBW9EU2W1brdRVkHx1p8H ODanP2xzUpqsrW9vFgQvh5n5hkk3vanFnVpXWVYwm0YgiDOrKy4UXC/7yQqE88gaa8uk4EEONuvh IMVE245PdD/7QgQIuwQVlN43iZQuK8mgm9qGOHi5bQ36INtC6ha7ADe1nEfRUhqsOCyU2NCupOz3 /GcU5MduvPjqbgd/jU+fyy1W8c0+lBp99D/fIDz1/h1+tY9aQRzD/5fwA+T6CQAA//8DAFBLAQIt ABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFw ZXhtbC54bWxQSwECLQAUAAYACAAAACEA31eGqcIAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJz L2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIcDAAAAAAAAD/AQAAAAc9kEAOBQOwDONwwAMiM+ AAAAEfAEAAAAAQAAAAAADfAEAAAAAAAuAA8ABPA5BQAAAgIK8AgAAABNBAAAQgsAAJMAC/BQAAAA fwAAAOsBvwEAABAAzgECAAAA0QEBAAAA/wEYABgAAwMAAAAAPwMIAAgAgMMaAAAAvwMAAAIAQQB1 AHQAbwBTAGgAYQBwAGUAIAA3ADgAAAAjACLxpQQAAKnDmQQAAKoDAAQAD1BLAwQUAAYACAAAACEA /iXrpQABAADqAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1OxCAQx+8mvgPhalqqB2NM6R6s HtWY9QEITFtiOxAG6+7bO93uXoxr4hHm//EbqDe7aRQzJPIBtbwuKykAbXAeey3ft0/FnRSUDToz BgQt90By01xe1Nt9BBLsRtJyyDneK0V2gMlQGSIgT7qQJpP5mHoVjf0wPaibqrpVNmAGzEVeMmRT t9CZzzGLxx1fryQJRpLiYRUuXVqaGEdvTWZSNaP70VIcG0p2HjQ0+EhXjCHVrw3L5HzB0ffCT5O8 A/FqUn42E2Mol2jZAMHmkFhX/p20oE5UhK7zFso2ES+1ek9w50pc+MIE83/zW7a9wXxKV4efar4B AAD//wMAUEsDBBQABgAIAAAAIQCWBTNY1AAAAJcBAAALAAAAX3JlbHMvLnJlbHOkkD1rAzEMhvdC /4PR3vMlQyklvmyFrCGFrsbWfZCzZCRzTf59TKGlV7J1lF70PC/a7S9pNguKTkwONk0LBilwnGhw 8H56e3oBo8VT9DMTOriiwr57fNgdcfalHuk4ZTWVQupgLCW/WqthxOS14YxUk54l+VJHGWz24ewH tNu2fbbymwHdimkO0YEc4hbM6Zqr+Q87TUFYuS9N4GS576dwj2ojf9IRl0rxMmBxEEW/loJLU8uB ve/d/NMbmAhDYfmojpX8J6n27wZ29c7uBgAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAA FAAAAGRycy9jb25uZWN0b3J4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x 07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAGH3mJu8AAAA2wAA AA8AAABkcnMvZG93bnJldi54bWxET8kKwjAQvQv+QxjBm6YWN6pRRBC9uiAeh2Zsq82kNNHWvzcH wePj7ct1a0rxptoVlhWMhhEI4tTqgjMFl/NuMAfhPLLG0jIp+JCD9arbWWKibcNHep98JkIIuwQV 5N5XiZQuzcmgG9qKOHB3Wxv0AdaZ1DU2IdyUMo6iqTRYcGjIsaJtTunz9DIKrq/ZLY5NtXmk+51+ xO2tcZOxUv1eu1mA8NT6v/jnPmgFszA2fAk/QK6+AAAA//8DAFBLAQItABQABgAIAAAAIQD+Jeul AAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25uZWN0b3J4bWwueG1sUEsB Ai0AFAAGAAgAAAAhAGH3mJu8AAAA2wAAAA8AAAAAAAAAAAAAAAAAoQIAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPkAAACKAwAAAAAAAA/wEAAAAPGKCgAJujwA1swOAFIzPgAAABHwBAAAAAEA AAAPAATwNwUAAKIMCvAIAAAATgQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAvAL8AAAAGAL8BEAAQ AP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADcAOQAAACMAIvGfBAAA qcOTBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tp FDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcv nY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W 4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98 J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsA AABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvq F/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhL SZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz3 3r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQU AAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy 1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYA CAAAACEAwYS3QMMAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP0WrCQBRE3wX/YbmFvohulJrU 1FW00JJXNR9wzV6T0OzdkF1N8vfdQsHHYWbOMNv9YBrxoM7VlhUsFxEI4sLqmksF+eVr/g7CeWSN jWVSMJKD/W462WKqbc8nepx9KQKEXYoKKu/bVEpXVGTQLWxLHLyb7Qz6ILtS6g77ADeNXEVRLA3W HBYqbOmzouLnfDcKblk/W2/667fPk9NbfMQ6udpRqdeX4fABwtPgn+H/dqYVJBv4+xJ+gNz9AgAA //8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIA AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAwYS3QMMAAADbAAAADwAAAAAAAAAAAAAA AACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIgDAAAAAAAAD/AQAAAAursCAMOb PQAVGgoAFW5AAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAvAA8ABPArBQAAMgAK8AgAAABPBAAAAgoA AIMAC/BAAAAAfwAAAO8BgAAAADAAvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMQAAAAvwMAAAIA TwB2AGEAbAAgADgAMAAAACMAIvGbBAAAqcOPBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAA AOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEim bdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMaya y4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu 8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wy hjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwME FAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNO b4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHh xJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdg qqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X /kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFw ZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VV qkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAvLU5078AAADbAAAADwAAAGRycy9kb3ducmV2 LnhtbERPTYvCMBC9C/6HMII3TbUoUo0iyoJ78LDd9T40Y1tsJqWZrfXfbw7CHh/ve3cYXKN66kLt 2cBinoAiLrytuTTw8/0x24AKgmyx8UwGXhTgsB+PdphZ/+Qv6nMpVQzhkKGBSqTNtA5FRQ7D3LfE kbv7zqFE2JXadviM4a7RyyRZa4c1x4YKWzpVVDzyX2fgXB7zda9TWaX380VWj9v1M10YM50Mxy0o oUH+xW/3xRrYxPXxS/wBev8HAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACP AQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5 AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQC8tTnT vwAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAA hAMAAAAAAAAP8BAAAABGTSkAU1c7AJ0sMQCDV0AAAAAR8AQAAAABAAAAAAAN8AQAAAAAADAADwAE 8D0FAAACAgrwCAAAAFAEAAACCwAAkwAL8FAAAAB/AAAA6wG/AQAAEADOAQIAAADRAQEAAAD/ARgA GAADAwAAAAA/AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADgAMQAAACMAIvGp BAAAqcOdBAAAqgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRzU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8Ruo N7tpFDMk8gG1vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZ IiBPupAmk/mYehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1 o/vRUhwbSnYeNDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMW yjYRL7V6T3DnSlz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAA lwEAAAsAAABfcmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1M oaVXsnWUXvQ8L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6Thl NZVC6mAsJb9aq2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5 L03gZLnvp3CPaiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD/ /wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/I zVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA //8DAFBLAwQUAAYACAAAACEAyyJDbcAAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPzYrCQBCE 7wu+w9DC3taJHiRER1FB2Osme9lbm+n8YKYnZlqNb+8sCB6LqvqKWm9H16kbDaH1bGA+S0ARl962 XBv4LY5fKaggyBY7z2TgQQG2m8nHGjPr7/xDt1xqFSEcMjTQiPSZ1qFsyGGY+Z44epUfHEqUQ63t gPcId51eJMlSO2w5LjTY06Gh8pxfnQFeXvrTQnDfSVqdxqoo8j9dGPM5HXcrUEKjvMOv9rc1kM7h /0v8AXrzBAAA//8DAFBLAQItABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAA AAAAAAAAMQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAA AAAAAAAALgIAAGRycy9jb25uZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhAMsiQ23AAAAA2wAA AA8AAAAAAAAAAAAAAAAAoQIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACOAwAAAAAA AA/wEAAAANV7LACvazgATz0tACxWOwAAABHwBAAAAAEAAAAPAATwPgUAAAICCvAIAAAAUQQAAAIL AACTAAvwUAAAAH8AAADrAb8BAAAQAM4BAgAAANEBAQAAAP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAA AL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAAOAAyAAAAIwAi8aoEAACpw54EAACqAwAEAA9QSwME FAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNTsQgEMfvJr4D 4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTyAbW8LispAG1wHnst 37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT+Zh6FY39MD2om6q6 VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtKdh40NPhIV4wh1a8N y+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpPcOdKXPjCBPN/81u2 vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAF9yZWxzLy5yZWxz pJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe9Dwv2u0vaTYLik5M DjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwlv1qrYcTkteGMVJOe JflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+ncI9qI3/SEZdK8TJg cRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwMEFAAGAAgAAAAhADMv BZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1L zk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQA7 8N0awQAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9Pa8JAFMTvgt9heYI33TQHCdFVbEHotUkv vT2zL38w+zbNPjV+e1co9DjMzG+Y3WFyvbrRGDrPBt7WCSjiytuOGwPf5WmVgQqCbLH3TAYeFOCw n892mFt/5y+6FdKoCOGQo4FWZMi1DlVLDsPaD8TRq/3oUKIcG21HvEe463WaJBvtsOO40OJAHy1V l+LqDPDmdzingu+9ZPV5qsuy+NGlMcvFdNyCEprkP/zX/rQGshReX+IP0PsnAAAA//8DAFBLAQIt ABQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAAAAAAAAAAAAAAAAMQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAAAAAAAAAAAAAAAALgIAAGRycy9jb25u ZWN0b3J4bWwueG1sUEsBAi0AFAAGAAgAAAAhADvw3RrBAAAA2wAAAA8AAAAAAAAAAAAAAAAAoQIA AGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPkAAACPAwAAAAAAAA/wEAAAADAlPAAhDzwAR3M+ ALQlPAAAABHwBAAAAAEAAAAPAATwNQUAAKIMCvAIAAAAUgQAAAIKAACDAAvwSAAAAH8AAADvAYAA AAAxAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAg ADgAMwAAACMAIvGdBAAAqcORBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAA W0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/e dD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsd KxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H 4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvK v1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAh ADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJ TGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/ 7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8 T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wX NXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyy sa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UC AAAA//8DAFBLAwQUAAYACAAAACEAlbnwjcEAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP3YrC MBSE7wXfIRzBG9HU9b8aZRVWvPXnAY7NsS02J6WJtr79RhC8HGbmG2a1aUwhnlS53LKC4SACQZxY nXOq4HL+689BOI+ssbBMCl7kYLNut1YYa1vzkZ4nn4oAYRejgsz7MpbSJRkZdANbEgfvZiuDPsgq lbrCOsBNIX+iaCoN5hwWMixpl1FyPz2Mgtuh7k0W9XXvL7PjeLrFfHa1L6W6neZ3CcJT47/hT/ug FcxH8P4SfoBc/wMAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAA AAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAA AAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAJW58I3BAAAA2wAA AA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACGAwAAAAAA AA/wEAAAAFMWOwDHgTgArnRCAFNXOwAAABHwBAAAAAEAAAAAAA3wBAAAAAAAMQAPAATwNgUAAKIM CvAIAAAAUwQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAAyAL8AAAAGAL8BEAAQAP8BAAAYAD8DAAAI AIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADgANAAAACMAIvGeBAAAqcOSBAAAqgMABAAP UEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH 74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0 N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ 3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUx QP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7Pb bHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4 jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8F nkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxL t1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAGlBo+cIA AADbAAAADwAAAGRycy9kb3ducmV2LnhtbESP0YrCMBRE3xf8h3AFXxZNFVdr1yi6oPha9QNum2tb trkpTbT17zeCsI/DzJxh1tve1OJBrassK5hOIhDEudUVFwqul8M4BuE8ssbaMil4koPtZvCxxkTb jlN6nH0hAoRdggpK75tESpeXZNBNbEMcvJttDfog20LqFrsAN7WcRdFCGqw4LJTY0E9J+e/5bhTc Tt3n16rLjv66TOeLPVbLzD6VGg373TcIT73/D7/bJ60gnsPrS/gBcvMHAAD//wMAUEsBAi0AFAAG AAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQAaUGj5wgAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhwMAAAAAAAAP8BAAAABHcz4AV9Y6AKLRRQCpqD0AAAAR 8AQAAAABAAAAAAAN8AQAAAAAADIADwAE8DUFAACiDArwCAAAAFQEAAACCgAAgwAL8EgAAAB/AAAA 7wGAAAAAMwC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBv AHgAIAA4ADUAAAAjACLxnQQAAKnDkQQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZ WHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0L xCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJp ZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUP GChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAI AAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksH uwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJ YN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CP bgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr 9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwu eG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVay t+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAHUczWLBAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxE j92qwjAQhO8F3yGs4I1oqhz/qlFUOOKtPw+wNmtbbDaliba+vREEL4eZ+YZZrhtTiCdVLresYDiI QBAnVuecKric//szEM4jaywsk4IXOViv2q0lxtrWfKTnyaciQNjFqCDzvoyldElGBt3AlsTBu9nK oA+ySqWusA5wU8hRFE2kwZzDQoYl7TJK7qeHUXA71L3xvL7u/WV6/JtsMZ9e7UupbqfZLEB4avwv /G0ftILZGD5fwg+QqzcAAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAA CwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAA EAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQB1HM1iwQAA ANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAhgMA AAAAAAAP8BAAAADq7iEAm4YvAEVNKQAnXDIAAAAR8AQAAAABAAAAAAAN8AQAAAAAADMADwAE8DcF AACiDArwCAAAAFUEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAANAC/AAAABgC/ARAAEAD/AQAAGAA/ AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA4ADYAAAAjACLxnwQAAKnDkwQAAKoD AAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1K xDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbgu KxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G 1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsOD DXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI 83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcw qZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0 nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13ii uVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAh ADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvO T8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAIXO UxXDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj9FqwkAURN8F/2G5hb6IbpSa2NRVtNCSVzUf cM1ek9Ds3ZBdTfL33ULBx2FmzjDb/WAa8aDO1ZYVLBcRCOLC6ppLBfnla74B4TyyxsYyKRjJwX43 nWwx1bbnEz3OvhQBwi5FBZX3bSqlKyoy6Ba2JQ7ezXYGfZBdKXWHfYCbRq6iKJYGaw4LFbb0WVHx c74bBbesn63f++u3z5PTW3zEOrnaUanXl+HwAcLT4J/h/3amFWxi+PsSfoDc/QIAAP//AwBQSwEC LQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hh cGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAIXOUxXDAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRy cy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAAAA/wEAAAAGF8KgCWCUMAzGY2ADdy RwAAABHwBAAAAAEAAAAAAA3wBAAAAAAANAAPAATwhgYAAAIACvAIAAAAVgQAAAIKAACTAgvwogEA AAQAAAAAAH8AAADvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8A AAAGAEABAAAAAEEBAAAAAEIBUgIAAEMBEgIAAEQBAgAAAEXBNAAAAEbBEgAAAFHBLgAAAFLBGgAA AFXBAAAAAFbBAAAAAFgBAgAAAH8BGQAZAIABAAAAAIEB////AIIBAAABAL8BAAAQAMABAAAAAMEB AAABAMQBAAAAAMsBNSUAANEBAQAAANQBAQAAANUBAQAAANYBAgAAAP8BGAAYAAQDAQAAAD8DAAAI AIDDGAAAAIgDAAAAAL8DAAACAA0ADQDw/zgBAADFAU8AUgKeAFIC9QBSAkwBmAEEAjcBCwLWABIC FAB5AQoAIgEAAMsA0gAwAPoAAAAGAAgAAgAAQAEgASABIAEgAIAFAAgACAC3BwMAAAAAANfEBQCx XgIAOgUDABkPBQDdGAAAIM4CAJFtAgAAAAAABQAIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAABGAHIA ZQBlAGYAbwByAG0AIAA4ADcAAAAjACLxoAQAAKnDlAQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeK u/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVd H2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGC HTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+ jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4x pmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMA UEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHa QxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2A koLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mV ERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMv c2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJ z0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAOvalmTEAAAA2wAAAA8AAABkcnMvZG93 bnJldi54bWxEj09rAjEUxO8Fv0N4greatULdbs2KlBbam9WleHxuXvePm5clibr99kYoeBxm5jfM cjWYTpzJ+caygtk0AUFcWt1wpaDYfTymIHxA1thZJgV/5GGVjx6WmGl74W86b0MlIoR9hgrqEPpM Sl/WZNBPbU8cvV/rDIYoXSW1w0uEm04+JcmzNNhwXKixp7eayuP2ZBTgi3x3802/+TksvsrZfN+m hW6VmoyH9SuIQEO4h//bn1pBuoDbl/gDZH4FAAD//wMAUEsBAi0AFAAGAAgAAAAhAPD3irv9AAAA 4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA Md1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA My8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAI AAAAIQDr2pZkxAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54bWxQSwUGAAAA AAQABAD1AAAAiQMAAAAAAAAP8BAAAABhfCoAJCdAADhBMACTR0UAAAAR8AQAAAABAAAADwAE8DkF AAACAgrwCAAAAFcEAAACCwAAgwAL8EoAAAB/AAAA6wG/AQAAEADRAQEAAAD/ARgAGAADAwAAAAA/ AwgACACAwxoAAAC/AwAAAgBBAHUAdABvAFMAaABhAHAAZQAgADgAOAAAACMAIvGrBAAAqcOfBAAA qgMABAAPUEsDBBQABgAIAAAAIQD+JeulAAEAAOoBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR zU7EIBDH7ya+A+FqWqoHY0zpHqwe1Zj1AQhMW2I7EAbr7ts73e5ejGviEeb/8RuoN7tpFDMk8gG1 vC4rKQBtcB57Ld+3T8WdFJQNOjMGBC33QHLTXF7U230EEuxG0nLIOd4rRXaAyVAZIiBPupAmk/mY ehWN/TA9qJuqulU2YAbMRV4yZFO30JnPMYvHHV+vJAlGkuJhFS5dWpoYR29NZlI1o/vRUhwbSnYe NDT4SFeMIdWvDcvkfMHR98JPk7wD8WpSfjYTYyiXaNkAweaQWFf+nbSgTlSErvMWyjYRL7V6T3Dn Slz4wgTzf/Nbtr3BfEpXh59qvgEAAP//AwBQSwMEFAAGAAgAAAAhAJYFM1jUAAAAlwEAAAsAAABf cmVscy8ucmVsc6SQPWsDMQyG90L/g9He8yVDKSW+bIWsIYWuxtZ9kLNkJHNN/n1MoaVXsnWUXvQ8 L9rtL2k2C4pOTA42TQsGKXCcaHDwfnp7egGjxVP0MxM6uKLCvnt82B1x9qUe6ThlNZVC6mAsJb9a q2HE5LXhjFSTniX5UkcZbPbh7Ae027Z9tvKbAd2KaQ7RgRziFszpmqv5DztNQVi5L03gZLnvp3CP aiN/0hGXSvEyYHEQRb+WgktTy4G979380xuYCENh+aiOlfwnqfbvBnb1zu4GAAD//wMAUEsDBBQA BgAIAAAAIQAzLwWeQQAAADkAAAAUAAAAZHJzL2Nvbm5lY3RvcnhtbC54bWyysa/IzVEoSy0qzszP s1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQU AAYACAAAACEAyX1x+MIAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPy2rCQBTdF/yH4QrdNRO7 KJpmEkSwFEsXPgjt7pK5TYKZO2Fm1NivdxaCy8N55+VoenEm5zvLCmZJCoK4trrjRsFhv36Zg/AB WWNvmRRcyUNZTJ5yzLS98JbOu9CIGMI+QwVtCEMmpa9bMugTOxBH7s86gyFC10jt8BLDTS9f0/RN Guw4NrQ40Kql+rg7GQU/X4tTda2+aVPNFptfdMb/7z+Uep6Oy3cQgcbwEN/dn1rBPI6NX+IPkMUN AAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAAAAAx AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAAAAAu AgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAyX1x+MIAAADbAAAADwAAAAAA AAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAJADAAAAAAAAD/AQAAAA S+M3AF7BMQBL4zcAjjs6AAAAEfAEAAAAAQAAAA8ABPA2BQAAogwK8AgAAABYBAAAAgoAAIMAC/BI AAAAfwAAAO8BgAAAADUAvwAAAAYAvwEQABAA/wEAABgAPwMAAAgAgMMYAAAAvwMAAAIAVABlAHgA dAAgAEIAbwB4ACAAOAA5AAAAIwAi8Z4EAACpw5IEAACqAwAEAA9QSwMEFAAGAAgAAAAhAPD3irv9 AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJHNSsQwEMfvgu8Q5iptqgcRaboHq0cVXR9g SKZt2DYJmVh33950Py7iCh5n5v/xI6lX22kUM0W23im4LisQ5LQ31vUKPtZPxR0ITugMjt6Rgh0x rJrLi3q9C8Qiux0rGFIK91KyHmhCLn0gly+djxOmPMZeBtQb7EneVNWt1N4lcqlISwY0dUsdfo5J PG7z+kASaWQQDwfh0qUAQxitxpRJ5ezMj5bi2FBm517Dgw18lTFA/tqwXM4XHH0v+WmiNSReMaZn nDKGNJElDxgoa8q/UxbMiQvfdVZT2UZ+X3wnqHPhxn+5SPN/s9tse6P5lC73P9R8AwAA//8DAFBL AwQUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAF9yZWxzLy5yZWxzpJDBasMwDIbvg72D0b1x2kMZ o05vhV5LB7sKW0lMY8tYJm3fvqYwWEZvO+oX+j7x7/a3MKmZsniOBtZNC4qiZefjYODrfFh9gJKC 0eHEkQzcSWDfvb/tTjRhqUcy+iSqUqIYGEtJn1qLHSmgNJwo1k3POWCpYx50QnvBgfSmbbc6/2ZA t2CqozOQj24D6nxP1fyHHbzNLNyXxnLQ3PfevqJqx9d4orlSMA9UDLgszzDT3NTnQL/2rv/plRET fVf+QvxMq/XHrBc1dg8AAAD//wMAUEsDBBQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAZHJzL3No YXBleG1sLnhtbLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9L tVWqTC1Wsrfj5QIAAAD//wMAUEsDBBQABgAIAAAAIQD0UcdnwgAAANsAAAAPAAAAZHJzL2Rvd25y ZXYueG1sRI/disIwFITvF3yHcARvFk0VV2s1yioo3vrzAKfNsS02J6XJ2vr2RhD2cpiZb5jVpjOV eFDjSssKxqMIBHFmdcm5gutlP4xBOI+ssbJMCp7kYLPufa0w0bblEz3OPhcBwi5BBYX3dSKlywoy 6Ea2Jg7ezTYGfZBNLnWDbYCbSk6iaCYNlhwWCqxpV1B2P/8ZBbdj+/2zaNODv85P09kWy3lqn0oN +t3vEoSnzv+HP+2jVhAv4P0l/AC5fgEAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWe QQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAh APRRx2fCAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APUAAACHAwAAAAAAAA/wEAAAABJfIAB8YRQAbb0nAAg3FwAAABHwBAAAAAEAAAAAAA3wBAAAAAAA NQAPAATwMAUAAKIMCvAIAAAAWQQAAAIKAACDAAvwSAAAAH8AAADvAYAAAAA2AL8AAAAGAL8BEAAQ AP8BAAAYAD8DAAAIAIDDGAAAAL8DAAACAFQAZQB4AHQAIABCAG8AeAAgADkAMAAAACMAIvGYBAAA qcOMBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tp FDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcv nY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W 4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98 J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsA AABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvq F/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhL SZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz3 3r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQU AAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy 1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYA CAAAACEA4LL4J7wAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPSwrCMBDdC94hjOBGNFX8VqOo oLj1c4CxGdtiMylNtPX2ZiG4fLz/atOYQrypcrllBcNBBII4sTrnVMHteujPQTiPrLGwTAo+5GCz brdWGGtb85neF5+KEMIuRgWZ92UspUsyMugGtiQO3MNWBn2AVSp1hXUIN4UcRdFUGsw5NGRY0j6j 5Hl5GQWPU92bLOr70d9m5/F0h/nsbj9KdTvNdgnCU+P/4p/7pBUswvrwJfwAuf4CAAD//wMAUEsB Ai0AFAAGAAgAAAAhAPD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3No YXBleG1sLnhtbFBLAQItABQABgAIAAAAIQDgsvgnvAAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABk cnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAgQMAAAAAAAAP8BAAAAAk8iEANWs4APJWKQDB QDsAAAAR8AQAAAABAAAAAAAN8AQAAAAAADYADwAE8DcFAACiDArwCAAAAFoEAAACCgAAgwAL8EgA AAB/AAAA7wGAAAAANwC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0 ACAAQgBvAHgAIAA5ADEAAAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0A AADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BI pm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGs msuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8 bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmec MoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsD BBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmj Tm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR 4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3 YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9 V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hh cGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1 VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhAI/+XbzDAAAA2wAAAA8AAABkcnMvZG93bnJl di54bWxEj9FqwkAURN+F/sNyC30R3Sg2apqNaKHiq9EPuGavSWj2bsiuJv59VxD6OMzMGSbdDKYR d+pcbVnBbBqBIC6srrlUcD79TFYgnEfW2FgmBQ9ysMneRikm2vZ8pHvuSxEg7BJUUHnfJlK6oiKD bmpb4uBdbWfQB9mVUnfYB7hp5DyKYmmw5rBQYUvfFRW/+c0ouB768ee6v+z9eXlcxDuslxf7UOrj fdh+gfA0+P/wq33QCtYzeH4JP0BmfwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h 0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWe QQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAh AI/+XbzDAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAE APUAAACIAwAAAAAAAA/wEAAAABJfIAA4gzwAbb0nAP1bPwAAABHwBAAAAAEAAAAAAA3wBAAAAAAA NwAPAATwPwUAAAICCvAIAAAAWwQAAIILAACTAAvwUAAAAH8AAADrAb8BAAAQAM4BAgAAANEBAQAA AP8BGAAYAAMDAAAAAD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAAOQAyAAAA IwAi8asEAACpw58EAACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVu dF9UeXBlc10ueG1slJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR 5v/xG6g3u2kUMyTyAbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itF doDJUBkiIE+6kCaT+Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhH b01mUjWj+9FSHBtKdh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBO VISu8xbKNhEvtXpPcOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUz WNQAAACXAQAACwAAAF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qk c03+fUyhpVeydZRe9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2 pR7pOGU1lULqYCwlv1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kP O01BWLkvTeBkue+ncI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO 7gYAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9yeG1sLnht bLKxr8jNUShLLSrOzM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj 5QIAAAD//wMAUEsDBBQABgAIAAAAIQCwE0mLwgAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI9P i8IwFMTvC36H8IS9ralhXbUaRQRxr/5BPD6aZ1ttXkoTbf32G0HY4zAzv2Hmy85W4kGNLx1rGA4S EMSZMyXnGo6HzdcEhA/IBivHpOFJHpaL3sccU+Na3tFjH3IRIexT1FCEUKdS+qwgi37gauLoXVxj MUTZ5NI02Ea4raRKkh9pseS4UGBN64Ky2/5uNZzu47NStl5ds+3GXFV3bv3oW+vPfreagQjUhf/w u/1rNEwVvL7EHyAXfwAAAP//AwBQSwECLQAUAAYACAAAACEA/iXrpQABAADqAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCWBTNY1AAAAJcBAAAL AAAAAAAAAAAAAAAAADEBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAU AAAAAAAAAAAAAAAAAC4CAABkcnMvY29ubmVjdG9yeG1sLnhtbFBLAQItABQABgAIAAAAIQCwE0mL wgAAANsAAAAPAAAAAAAAAAAAAAAAAKECAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD5AAAA kAMAAAAAAAAP8BAAAACa7iEA2j87AJ+kJQDR9jwAAAAR8AQAAAABAAAADwAE8DUFAACiDArwCAAA AFwEAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAAOAC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgA AAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA5ADMAAAAjACLxnQQAAKnDkQQAAKoDAAQAD1BLAwQU AAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDm Km2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+ 1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsYUgr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U 3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HSpQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBc zhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9TFsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mU Lvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFq wzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxjy1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0L iqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1ONGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKlj HnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V/IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzP MNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAA OQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGvyM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x 07VQUiguScxLSczJz0u1VapMLVayt+PlAgAAAP//AwBQSwMEFAAGAAgAAAAhABBgZlDBAAAA2wAA AA8AAABkcnMvZG93bnJldi54bWxEj92KwjAUhO+FfYdwFrwRTdd/q1FUULz15wGOzbEtNielydr6 9kYQvBxm5htmsWpMIR5Uudyygr9eBII4sTrnVMHlvOtOQTiPrLGwTAqe5GC1/GktMNa25iM9Tj4V AcIuRgWZ92UspUsyMuh6tiQO3s1WBn2QVSp1hXWAm0L2o2gsDeYcFjIsaZtRcj/9GwW3Q90Zzerr 3l8mx+F4g/nkap9KtX+b9RyEp8Z/w5/2QSuYDeD9JfwAuXwBAAD//wMAUEsBAi0AFAAGAAgAAAAh APD3irv9AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAMd1fYdIAAACPAQAACwAAAAAAAAAAAAAAAAAuAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAAAAAAAAAAAAAAApAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQAQYGZQwQAAANsAAAAPAAAAAAAAAAAAAAAAAJgCAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAAhgMAAAAAAAAP8BAAAAC14y8ANDIgAL1LNwDAByMAAAAR8AQAAAAB AAAAAAAN8AQAAAAAADgADwAE8DcFAACiDArwCAAAAF0EAAACCgAAgwAL8EgAAAB/AAAA7wGAAAAA OQC/AAAABgC/ARAAEAD/AQAAGAA/AwAACACAwxgAAAC/AwAAAgBUAGUAeAB0ACAAQgBvAHgAIAA5 ADQAAAAjACLxnwQAAKnDkwQAAKoDAAQAD1BLAwQUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkc1KxDAQx++C7xDmKm2qBxFpugerRxVdH2BIpm3YNgmZWHff3nQ/ LuIKHmfm//EjqVfbaRQzRbbeKbguKxDktDfW9Qo+1k/FHQhO6AyO3pGCHTGsmsuLer0LxCK7HSsY Ugr3UrIeaEIufSCXL52PE6Y8xl4G1BvsSd5U1a3U3iVyqUhLBjR1Sx1+jkk8bvP6QBJpZBAPB+HS pQBDGK3GlEnl7MyPluLYUGbnXsODDXyVMUD+2rBczhccfS/5aaI1JF4xpmecMoY0kSUPGChryr9T FsyJC991VlPZRn5ffCeoc+HGf7lI83+z22x7o/mULvc/1HwDAAD//wMAUEsDBBQABgAIAAAAIQAx 3V9h0gAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkMFqwzAMhu+DvYPRvXHaQxmjTm+FXksHuwpbSUxj y1gmbd++pjBYRm876hf6PvHv9rcwqZmyeI4G1k0LiqJl5+Ng4Ot8WH2AkoLR4cSRDNxJYN+9v+1O NGGpRzL6JKpSohgYS0mfWosdKaA0nCjWTc85YKljHnRCe8GB9KZttzr/ZkC3YKqjM5CPbgPqfE/V /IcdvM0s3JfGctDc996+omrH13iiuVIwD1QMuCzPMNPc1OdAv/au/+mVERN9V/5C/Eyr9cesFzV2 DwAAAP//AwBQSwMEFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAABkcnMvc2hhcGV4bWwueG1ssrGv yM1RKEstKs7Mz7NVMtQzUFJIzUvOT8nMS7dVCg1x07VQUiguScxLSczJz0u1VapMLVayt+PlAgAA AP//AwBQSwMEFAAGAAgAAAAhAJ+J/iTDAAAA2wAAAA8AAABkcnMvZG93bnJldi54bWxEj92KwjAU hO8XfIdwBG8WmyquP12j6ILibdUHOG2ObdnmpDTR1rffCMJeDjPzDbPe9qYWD2pdZVnBJIpBEOdW V1wouF4O4yUI55E11pZJwZMcbDeDjzUm2nac0uPsCxEg7BJUUHrfJFK6vCSDLrINcfButjXog2wL qVvsAtzUchrHc2mw4rBQYkM/JeW/57tRcDt1n1+rLjv66yKdzfdYLTL7VGo07HffIDz1/j/8bp+0 gtUMXl/CD5CbPwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAA AAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAA AAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAJ+J/iTDAAAA2wAA AA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACIAwAAAAAA AA/wEAAAAKRQLgB0zCMA/641AHOoJgAAABHwBAAAAAEAAAAAAA3wBAAAAAAAOQAPAATwQAUAAAIC CvAIAAAAXgQAAIILAACTAAvwUAAAAH8AAADrAb8BAAAQAM4BAgAAANEBAQAAAP8BGAAYAAMDAAAA AD8DCAAIAIDDGgAAAL8DAAACAEEAdQB0AG8AUwBoAGEAcABlACAAOQA1AAAAIwAi8awEAACpw6AE AACqAwAEAA9QSwMEFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAABbQ29udGVudF9UeXBlc10ueG1s lJHNTsQgEMfvJr4D4WpaqgdjTOkerB7VmPUBCExbYjsQBuvu2zvd7l6Ma+IR5v/xG6g3u2kUMyTy AbW8LispAG1wHnst37dPxZ0UlA06MwYELfdActNcXtTbfQQS7EbScsg53itFdoDJUBkiIE+6kCaT +Zh6FY39MD2om6q6VTZgBsxFXjJkU7fQmc8xi8cdX68kCUaS4mEVLl1amhhHb01mUjWj+9FSHBtK dh40NPhIV4wh1a8Ny+R8wdH3wk+TvAPxalJ+NhNjKJdo2QDB5pBYV/6dtKBOVISu8xbKNhEvtXpP cOdKXPjCBPN/81u2vcF8SleHn2q+AQAA//8DAFBLAwQUAAYACAAAACEAlgUzWNQAAACXAQAACwAA AF9yZWxzLy5yZWxzpJA9awMxDIb3Qv+D0d7zJUMpJb5shawhha7G1n2Qs2Qkc03+fUyhpVeydZRe 9Dwv2u0vaTYLik5MDjZNCwYpcJxocPB+ent6AaPFU/QzEzq4osK+e3zYHXH2pR7pOGU1lULqYCwl v1qrYcTkteGMVJOeJflSRxls9uHsB7Tbtn228psB3YppDtGBHOIWzOmaq/kPO01BWLkvTeBkue+n cI9qI3/SEZdK8TJgcRBFv5aCS1PLgb3v3fzTG5gIQ2H5qI6V/Cep9u8GdvXO7gYAAP//AwBQSwME FAAGAAgAAAAhADMvBZ5BAAAAOQAAABQAAABkcnMvY29ubmVjdG9yeG1sLnhtbLKxr8jNUShLLSrO zM+zVTLUM1BSSM1Lzk/JzEu3VQoNcdO1UFIoLknMS0nMyc9LtVWqTC1Wsrfj5QIAAAD//wMAUEsD BBQABgAIAAAAIQA/+tH/wwAAANsAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/NasMwEITvhbyD2EBv jVxTN61jJYSCaa9xQshxsTb+qbUylmK7b18VAj0OM/MNk+1m04mRBtdYVvC8ikAQl1Y3XCk4HfOn NxDOI2vsLJOCH3Kw2y4eMky1nfhAY+ErESDsUlRQe9+nUrqyJoNuZXvi4F3tYNAHOVRSDzgFuOlk HEWv0mDDYaHGnj5qKr+Lm1Fwvq0vcWz6fVt+5rqN58vkkhelHpfzfgPC0+z/w/f2l1bwnsDfl/AD 5PYXAAD//wMAUEsBAi0AFAAGAAgAAAAhAP4l66UAAQAA6gEAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAlgUzWNQAAACXAQAACwAAAAAAAAAAAAAA AAAxAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAMy8FnkEAAAA5AAAAFAAAAAAAAAAAAAAA AAAuAgAAZHJzL2Nvbm5lY3RvcnhtbC54bWxQSwECLQAUAAYACAAAACEAP/rR/8MAAADbAAAADwAA AAAAAAAAAAAAAAChAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA+QAAAJEDAAAAAAAAD/AQ AAAAOEEwAP2JIgA89TMAikAkAAAAEfAEAAAAAQAAAA8ABPAvBQAAMgAK8AgAAABfBAAAAgoAAIMA C/BAAAAAfwAAAO8BgAAAADoAvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMQAAAAvwMAAAIATwB2 AGEAbAAgADkANgAAACMAIvGfBAAAqcOTBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2 CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6 vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pA EmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSR JQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAG AAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4Ve Swe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM 3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMz kI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8 TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXht bC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwt VrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEA2cmS4cMAAADbAAAADwAAAGRycy9kb3ducmV2Lnht bESPQWvCQBSE70L/w/IKvelGg6FNXUUqBT300NjeH9lnEsy+DdlnjP/eFQo9DjPzDbPajK5VA/Wh 8WxgPktAEZfeNlwZ+Dl+Tl9BBUG22HomAzcKsFk/TVaYW3/lbxoKqVSEcMjRQC3S5VqHsiaHYeY7 4uidfO9QouwrbXu8Rrhr9SJJMu2w4bhQY0cfNZXn4uIM7KptkQ06lWV62u1lef79OqRzY16ex+07 KKFR/sN/7b018JbB40v8AXp9BwAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAA jwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAA OQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA2cmS 4cMAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAA AIgDAAAAAAAAD/AQAAAAVMonAMAHIwA4QTAAytonAAAAEfAEAAAAAQAAAAAADfAEAAAAAAA6AA8A BPAvBQAAMgAK8AgAAABgBAAAAgoAAIMAC/BAAAAAfwAAAO8BgAAAADsAvwAAAAYAvwEQABAA/wEI ABgAPwMAAAgAgMMQAAAAvwMAAAIATwB2AGEAbAAgADkANwAAACMAIvGfBAAAqcOTBAAAqgMABAAP UEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH 74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0 N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ 3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUx QP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7Pb bHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVs c6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4 jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZN zzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAP VAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8F nkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxL t1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAtoU3esMA AADbAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvCQBSE70L/w/IKvenGBq1GV5FKwR48NOr9kX0m wezbkH2N6b/vFgoeh5n5hllvB9eonrpQezYwnSSgiAtvay4NnE8f4wWoIMgWG89k4IcCbDdPozVm 1t/5i/pcShUhHDI0UIm0mdahqMhhmPiWOHpX3zmUKLtS2w7vEe4a/Zokc+2w5rhQYUvvFRW3/NsZ 2Je7fN7rVGbpdX+Q2e1y/Eynxrw8D7sVKKFBHuH/9sEaWL7B35f4A/TmFwAA//8DAFBLAQItABQA BgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAAAAAAAAAALgEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAAAAAAAAAAKQIAAGRycy9zaGFwZXht bC54bWxQSwECLQAUAAYACAAAACEAtoU3esMAAADbAAAADwAAAAAAAAAAAAAAAACYAgAAZHJzL2Rv d25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIgDAAAAAAAAD/AQAAAA2EwaAEaaFQAZGiEAkwwaAAAA EfAEAAAAAQAAAAAADfAEAAAAAAA7AA8ABPAsBQAAMgAK8AgAAABhBAAAAgoAAIMAC/BAAAAAfwAA AO8BgAAAADwAvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMQAAAAvwMAAAIATwB2AGEAbAAgADkA OAAAACMAIvGcBAAAqcOQBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u 4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhS CvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKl AEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MW zIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHd X2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPL WCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40 YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8 hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYP AAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/I zVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA //8DAFBLAwQUAAYACAAAACEAxxqjCMAAAADbAAAADwAAAGRycy9kb3ducmV2LnhtbERPTWvCQBC9 F/wPywje6kaD0qauIopgDz001fuQHZNgdjZkxxj/ffcgeHy879VmcI3qqQu1ZwOzaQKKuPC25tLA 6e/w/gEqCLLFxjMZeFCAzXr0tsLM+jv/Up9LqWIIhwwNVCJtpnUoKnIYpr4ljtzFdw4lwq7UtsN7 DHeNnifJUjusOTZU2NKuouKa35yBfbnNl71OZZFe9kdZXM8/3+nMmMl42H6BEhrkJX66j9bAZxwb v8QfoNf/AAAA//8DAFBLAQItABQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAAAAAAAA AAAAAAAALgEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhADMvBZ5BAAAAOQAAABAAAAAAAAAA AAAAAAAAKQIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAxxqjCMAAAADbAAAADwAA AAAAAAAAAAAAAACYAgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAIUDAAAAAAAAD/AQ AAAAoEI0AHM/GAC9HjwAoz8dAAAAEfAEAAAAAQAAAAAADfAEAAAAAAA8AA8ABPAwBQAAMgAK8AgA AABiBAAAAgoAAIMAC/BAAAAAfwAAAO8BgAAAAD0AvwAAAAYAvwEQABAA/wEIABgAPwMAAAgAgMMQ AAAAvwMAAAIATwB2AGEAbAAgADkAOQAAACMAIvGgBAAAqcOUBAAAqgMABAAPUEsDBBQABgAIAAAA IQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6 B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOpV9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7o DI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsG NHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXszI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lp ojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lGfl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMA AP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9 g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhGbzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg 63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKiGBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0 pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/ 9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBLAwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAA AGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszPs1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5J zEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQUAAYACAAAACEAqFYGk8QAAADbAAAADwAAAGRy cy9kb3ducmV2LnhtbESPQWvCQBSE74X+h+UJvdWNDUqNrhIaCnrowbS9P7LPJJh9G7KvMf33XaHg cZiZb5jtfnKdGmkIrWcDi3kCirjytuXawNfn+/MrqCDIFjvPZOCXAux3jw9bzKy/8onGUmoVIRwy NNCI9JnWoWrIYZj7njh6Zz84lCiHWtsBrxHuOv2SJCvtsOW40GBPbw1Vl/LHGSjqvFyNOpVlei4O srx8fxzThTFPsynfgBKa5B7+bx+sgfUabl/iD9C7PwAAAP//AwBQSwECLQAUAAYACAAAACEA8PeK u/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAAAC4BAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAAACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0A FAAGAAgAAAAhAKhWBpPEAAAA2wAAAA8AAAAAAAAAAAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBL BQYAAAAABAAEAPUAAACJAwAAAAAAAA/wEAAAAD97GQAsjDoA6u4hADZfPwAAABHwBAAAAAEAAAAA AA3wBAAAAAAAPQAPAATwMgUAADIACvAIAAAAYwQAAAIKAACDAAvwQgAAAH8AAADvAYAAAAA+AL8A AAAGAL8BEAAQAP8BCAAYAD8DAAAIAIDDEgAAAL8DAAACAE8AdgBhAGwAIAAxADAAMAAAACMAIvGg BAAAqcOUBAAAqgMABAAPUEsDBBQABgAIAAAAIQDw94q7/QAAAOIBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRzUrEMBDH74LvEOYqbaoHEWm6B6tHFV0fYEimbdg2CZlYd9/edD8u4goeZ+b/8SOp V9tpFDNFtt4puC4rEOS0N9b1Cj7WT8UdCE7oDI7ekYIdMayay4t6vQvEIrsdKxhSCvdSsh5oQi59 IJcvnY8TpjzGXgbUG+xJ3lTVrdTeJXKpSEsGNHVLHX6OSTxu8/pAEmlkEA8H4dKlAEMYrcaUSeXs zI+W4thQZudew4MNfJUxQP7asFzOFxx9L/lpojUkXjGmZ5wyhjSRJQ8YKGvKv1MWzIkL33VWU9lG fl98J6hz4cZ/uUjzf7PbbHuj+ZQu9z/UfAMAAP//AwBQSwMEFAAGAAgAAAAhADHdX2HSAAAAjwEA AAsAAABfcmVscy8ucmVsc6SQwWrDMAyG74O9g9G9cdpDGaNOb4VeSwe7CltJTGPLWCZt376mMFhG bzvqF/o+8e/2tzCpmbJ4jgbWTQuKomXn42Dg63xYfYCSgtHhxJEM3Elg372/7U40YalHMvokqlKi GBhLSZ9aix0poDScKNZNzzlgqWMedEJ7wYH0pm23Ov9mQLdgqqMzkI9uA+p8T9X8hx28zSzcl8Zy 0Nz33r6iasfXeKK5UjAPVAy4LM8w09zU50C/9q7/6ZURE31X/kL8TKv1x6wXNXYPAAAA//8DAFBL AwQUAAYACAAAACEAMy8FnkEAAAA5AAAAEAAAAGRycy9zaGFwZXhtbC54bWyysa/IzVEoSy0qzszP s1Uy1DNQUkjNS85PycxLt1UKDXHTtVBSKC5JzEtJzMnPS7VVqkwtVrK34+UCAAAA//8DAFBLAwQU AAYACAAAACEA4aFp7sQAAADcAAAADwAAAGRycy9kb3ducmV2LnhtbESPQWvCQBCF74X+h2UKvdWN BkVSVxGlYA89NNr7kB2TYHY2ZKcx/fedQ6G3Gd6b977Z7KbQmZGG1EZ2MJ9lYIir6FuuHVzOby9r MEmQPXaRycEPJdhtHx82WPh4508aS6mNhnAq0EEj0hfWpqqhgGkWe2LVrnEIKLoOtfUD3jU8dHaR ZSsbsGVtaLCnQ0PVrfwODo71vlyNNpdlfj2eZHn7+njP5849P037VzBCk/yb/65PXvEzxddndAK7 /QUAAP//AwBQSwECLQAUAAYACAAAACEA8PeKu/0AAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAx3V9h0gAAAI8BAAALAAAAAAAAAAAAAAAA AC4BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAzLwWeQQAAADkAAAAQAAAAAAAAAAAAAAAA ACkCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAOGhae7EAAAA3AAAAA8AAAAAAAAA AAAAAAAAmAIAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAACJAwAAAAAAAA/wEAAAAJWl EQD0tAoAkTUYAJUdDwAAABHwBAAAAAEAAAAAAA3wBAAAAAAAPgAPAATwQgAAABIACvAIAAAAAQQA AAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAO8B BfDAAwAAAQAS8BgAAAABAAAABQQAAGMEAAAGBAAABAAAAAAAAAABABLwGAAAAAIAAAAFBAAABwQA AAgEAAAEAAAAAAAAAAEAEvAYAAAAAwAAADwEAAAMBAAADgQAAAQAAAAAAAAAAQAS8BgAAAAEAAAA YwQAAAAAAAAPBAAABAAAAP////8BABLwGAAAAAUAAABgBAAAEAQAABIEAAAEAAAAAAAAAAEAEvAY AAAABgAAAAwEAAAUBAAAFwQAAAQAAAAAAAAAAQAS8BgAAAAHAAAAEAQAABUEAAAZBAAABAAAAAAA AAABABLwGAAAAAgAAAAQBAAAXwQAABsEAAAGAAAAAgAAAAEAEvAYAAAACQAAAGAEAABfBAAAHAQA AAQAAAAAAAAAAQAS8BgAAAAKAAAAFAQAAB0EAAAfBAAABAAAAAAAAAABABLwGAAAAAsAAAAVBAAA YgQAACEEAAAEAAAAAAAAAAEAEvAYAAAADAAAAF8EAAAkBAAAIwQAAAUAAAAAAAAAAQAS8BgAAAAN AAAABwQAAAAAAAAmBAAABAAAAP////8BABLwGAAAAA4AAABhBAAAJAQAACgEAAAEAAAAAAAAAAEA EvAYAAAADwAAACQEAAAAAAAAMQQAAAYAAAD/////AQAS8BgAAAAQAAAAAAAAAAAAAAA0BAAA//// //////8BABLwGAAAABEAAAAAAAAAAAAAADYEAAD//////////wEAEvAYAAAAEgAAAAAAAAAAAAAA OAQAAP//////////AQAS8BgAAAATAAAAAAAAAAAAAAA6BAAA//////////8BABLwGAAAABQAAABj BAAAPAQAAD8EAAAEAAAAAAAAAAEAEvAYAAAAFQAAAGMEAAAAAAAAQAQAAAQAAAD/////AQAS8BgA AAAWAAAAAAAAAAAAAABEBAAA//////////8BABLwGAAAABcAAAAAAAAAAAAAAEcEAAD///////// /wEAEvAYAAAAGAAAAAAAAAAAAAAASgQAAP//////////AQAS8BgAAAAZAAAAAAAAAAAAAABNBAAA //////////8BABLwGAAAABoAAAAAAAAATwQAAFAEAAD/////AAAAAAEAEvAYAAAAGwAAAAAAAAAA AAAAUQQAAP//////////AQAS8BgAAAAcAAAAJAQAAAAAAABXBAAABAAAAP////8BABLwGAAAAB0A AABiBAAAWQQAAFsEAAAGAAAAAgAAAAEAEvAYAAAAHgAAAAAAAAAAAAAAXgQAAP//////////GQAA AJ0DAAACBAAAAAAAAAAAAADdNQAAezgAAHSAAAAAAAAAAAAdAAAATwAAAFIAAABkAAAAZwAAAH0A AACBAAAAogAAAKYAAADCAAAAxgAAAOQAAADoAAAANAEAADgBAACTAQAAlgEAAPEBAAD1AQAAFAIA ABgCAACbAwAAngMAAAcABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA AwAAAAAAHQAAACcAAAA9AAAAQgAAAH0AAACBAAAAjwAAAJUAAACiAAAApgAAALQAAAC6AAAAwgAA AMYAAADUAAAA2gAAAOQAAADoAAAAEwEAABgBAAAgAQAAJQEAAC0BAAAvAQAANAEAADgBAABNAQAA UwEAAGUBAABrAQAAvgEAAMQBAADVAQAA2wEAAPkBAAD/AQAAHAIAACICAAAyAgAANQIAAD8CAABB AgAASQIAAEsCAABTAgAAVQIAAF0CAABgAgAAagIAAGwCAAB5AgAAfAIAAIYCAACJAgAAkwIAAJUC AACdAgAAnwIAAKcCAACqAgAAtAIAALYCAAC+AgAAwQIAAMsCAADNAgAA1QIAANgCAADiAgAA5AIA AOwCAADvAgAA+QIAAPsCAAAKAwAADQMAABcDAAAZAwAAIQMAACQDAABFAwAASAMAAFIDAABUAwAA XAMAAF8DAABpAwAAawMAAHMDAAB2AwAAmwMAAJ4DAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAMAAAAAAB0AAAAyAAAA NAAAADYAAAA4AAAAOwAAAD0AAABNAAAATwAAAGIAAABkAAAAdgAAAHgAAAB7AAAAfQAAAJsAAACd AAAAoAAAAKIAAADAAAAA5AAAAPcAAAD5AAAA/QAAAP8AAAADAQAABQEAAB4BAAAgAQAAKwEAAEcB AABLAQAATQEAAGMBAABlAQAAegEAAHwBAACLAQAAjQEAAJEBAACTAQAApQEAAKcBAAC2AQAAuAEA ALwBAAC+AQAA0wEAABwCAAAwAgAAMgIAAD0CAAA/AgAARwIAAEkCAABRAgAAUwIAAFsCAABdAgAA aAIAAGoCAAByAgAAdAIAAHcCAAB5AgAAhAIAAIYCAACRAgAAkwIAAJsCAACdAgAApQIAAKcCAACy AgAAtAIAALwCAAC+AgAAyQIAAMsCAADTAgAA1QIAAOACAADiAgAA6gIAAOwCAAD3AgAA+QIAAAED AAADAwAACAMAAAoDAAAVAwAAFwMAAB8DAAAhAwAALAMAAC4DAABDAwAARQMAAFADAABSAwAAWgMA AFwDAABnAwAAaQMAAHEDAABzAwAAfgMAAIADAACEAwAAhgMAAIkDAACLAwAAjwMAAJEDAACVAwAA lwMAAJkDAACbAwAAngMAAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwADAAQAAAAEAAAACAAAAOUAAAAAAAAAAgAAABkbLABr BlkAVyNaAHUW7QAAAAAAHQAAAB8AAAAAAAAAAQAAAP9AAQEBAAAAAAAcAAAAAAAAAAEAAQAZAAAA AAAAAGMAAAAAAAAAAhAAAAAAAAAAnQMAABABABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP// AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABHHpABAAAC AgYDBQQFAgME/yoA4EF4AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAAA1HpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBv AGwAAAAzLpABAAACCwYEAgICAgIE/yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAA Ny6QAQAAAg8FAgICBAMCBP8CAOD/rABAAQAAAAAAAACfAQAAAAAAAEMAYQBsAGkAYgByAGkAAABB HpABAAACBAUDBQQGAwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0A YQB0AGgAAAAiAAQAcQiIGADw0AIAAGgBAAAAACgLa4cpC2uHAAAAAAEAAQAAAAQAAAAZAAAAAQAB AAAABAADkAEAAACJAAAAEgMAAAEAAQAAAAYAAAAAAAAAcQMA8BAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAoAWgBbQAtACBgTIwAAAAAAAAAAAAAAAAAAAcAAAAmgMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAB S4NRAPAQAAgA/P0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEhQAAAAAAnw/w8ACSRQAADkBAAA ////f////3////9/////f////3////9/////f2sGWQAABgAAMgAAAAAAAAAAAAAAAAAAAAAAAAAA ACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAQAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAAAA AAALAAAAAAAAANwAAAD//xIAAAAAAAAAAAAAAAAAAAAQAEoAbwBuAGEAdABoAGEAbgAgAEgAYQBt AG0AZQBsAGwAEABKAG8AbgBhAHQAaABhAG4AIABIAGEAbQBtAGUAbABsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAANAEAAA0AAAABAAAAcAAAAAQAAAB4AAAABwAAAJQAAAAIAAAAqAAAAAkAAADE AAAAEgAAANAAAAAKAAAA8AAAAAwAAAD8AAAADQAAAAgBAAAOAAAAFAEAAA8AAAAcAQAAEAAAACQB AAATAAAALAEAAAIAAADkBAAAHgAAABQAAABKb25hdGhhbiBIYW1tZWxsAAAAAB4AAAAMAAAATm9y bWFsLmRvdG0AHgAAABQAAABKb25hdGhhbiBIYW1tZWxsAAAAAB4AAAAEAAAAMQAAAB4AAAAYAAAA TWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABGwyMAAAAAQAAAAADw1IcBctQBQAAAAAA2mKsB ctQBAwAAAAEAAAADAAAABAAAAAMAAAAZAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmu MAAAAPAAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAAAIwAAAARAAAAlAAAABcAAACc AAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwAAAANAAAAxAAAAAwAAADRAAAAAgAAAOQE AAAeAAAADAAAAENTRUMtQ1NUQwAAAAMAAAABAAAAAwAAAAEAAAADAAAAHAAAAAMAAAAAAA4ACwAA AAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAABgAA AFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAD+////FAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAAP7///8c AAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoA AAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAA ADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAA RwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABV AAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMA AABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAA AHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAA gAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACO AAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwA AACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAA AKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAA uQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADH AAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUA AADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAA AOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA 8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8AAAAA AQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4B AAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAAHAEA AB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEAACkBAAAqAQAA KwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAANwEAADgBAAA5 AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAA/v///0EBAABCAQAAQwEAAEQBAABFAQAARgEAAEcB AAD+////SQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAP7////9/////f////3///9UAQAA/v// //7////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABA7MjF AXLUAVYBAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAuEkCAAAAAABXAG8AcgBkAEQAbwBj AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIA AAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuJAAAAAAA AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAQAEAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABIAQAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8B AP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGIAAAAE1pY3Jvc29mdCBXb3JkIDk3LTIwMDMgRG9j dW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --_003_58976649956f45ed8f81214ee4468978cybergcca_-- From nobody Fri Nov 2 01:23:57 2018 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 1F88112F18C; Fri, 2 Nov 2018 01:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 8EC39q54S9a5; Fri, 2 Nov 2018 01:23:53 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4D75212008A; Fri, 2 Nov 2018 01:23:53 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id p17so760952lfh.4; Fri, 02 Nov 2018 01:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Px+NRn9zf897ztc1NoaQAWmcKVS+FRNVK8SgqugMMCc=; b=jJAwb7EFtOQcyKWcdxfBvpAlwKz9+CN1dKT9jqicw75NnbMyQYavNJ5d8iGkIPcUfh /0Sd36OBeRswL/cGx/axJcoal22S4NPhhOh/Ca1o0lwrx+mI9BZZLtL692LPV+toQgjz 3n/6XrBBe77QKS08inCNqNE/0Y0hhwzOhEJv2V6/cUQdU5sQt0lDJHNB7vStNWeDW0vz 5dCNpyHEgnPTpMCZOE7fvu90bsAeJ/BqCn8QhizxX+DiK1hiDmA0panNCDhgmyc76/gh C4Zu5Du1QVszrEyoWdPS27K/aWmlR2ChzPmNKZSHkhpWEP0r3J/0uOtacViE50mX7OVm 2uwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=Px+NRn9zf897ztc1NoaQAWmcKVS+FRNVK8SgqugMMCc=; b=ZWfnZgDaV+cGhxF5GQOSgqJM45myr+4pfuU5gj19OBc4yR4cWVkftY22YGbqg/wGQ3 irlYJkYX04+6wl3eI1gJ8hiheGFxQlntCpPGr+V2lHn3zeeewfIVh6YFK9X/KlMR+4k7 OuG5wYogoT3t10VE+/wKuBLSVPWLQV8shAbpGsLV1xaliwKpchi4uNmisCBqNGTsJ/z7 mIMaTbXAxVglz3mukDhdUQzM7edduAxW1MaraaGr8vm10rHcT3JJo7QqAlX/S4dqqysG RdKkT4R8U8LePPaGzL2NRODO/1kiLzjIQLhgn9yhNuIkhcS3PxQbGaKQB+/eo2vRzPrG YENA== X-Gm-Message-State: AGRZ1gKdW+czeXmjhpxjU4WnIBukXjDoC/gBliCAk77GSgwV+EcFNnFm Rtq3Y7X/nZCcWovrjBVxAVF6Tz75 X-Google-Smtp-Source: AJdET5c0QJRLJgkh0IYCt5GFWIgkvuyYP3T0FxDoxjKvGqx0twi/LxTL+YmLQjCHnXNFalt01UhuAQ== X-Received: by 2002:a19:2a9a:: with SMTP id q26mr5953964lfq.94.1541147030645; Fri, 02 Nov 2018 01:23:50 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p19-v6sm2477151ljb.47.2018.11.02.01.23.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Nov 2018 01:23:50 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'IPsecME WG'" Cc: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> In-Reply-To: Date: Fri, 2 Nov 2018 11:23:35 +0300 Message-ID: <086b01d47285$5a161340$0e4239c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQBiexsmH6yYgnMQDSohT/oic8CpEgFU4nhiAfgiA5cC+Fx/Kaft0llg Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 08:23:55 -0000 > > > > 1. Nonces. > > > > > > > > The draft specifies that each additional key exchange performed > > > > over IKE_AUX includes new nonces. My question - why nonces > > exchanged > > > > during IKE_SA_INIT cannot be used instead? Is it critical for security? > > > > > > No, it is not. Instead, we were (mostly) reusing the format of the > > > CREATE_CHILD_SA request; as that request already had nonces, we saw no > > specific reason to remove them. > > Correction to what I said: the original reasoning was not to keep the IKE message format, but rather to reuse > the IKE child SA key derivation function (section 2.17) That's how I understood it. > > It's true that AUX_I (f collision resistant PRF of initiator's IKE_AUX messages) > > is included in the initiator's signature. > > My concern is: from my recollection of SIGMA paper it is essential for security > > that each party includes its peer's nonce in the signature. In case of IKE > > initiator, the NonceRData is responder's nonce (from IKE_SA_INIT) and it is > > included. > > But the AUX_I contains only PRF over initiator's messages, i.e. it contains only > > initiator's additional nonces, not responder's ones. > > Is it OK for authentication that we don't include peer's additional nonces in > > the signature? Won't we screw up SIGMA? > > (Disclaimer: I'm not a cryptographer). > > The nonces are included; however instead of including the text of the nonce directly, we're including a > complex function of (among other things) the nonces. If you change the nonces, you change the output of > that complex function, which changes the text of what is signed, and that is what SIGMA relies on. Sorry for being tedious, I just want to eliminate all possible misunderstanding. I understand that the nonces exchanged in IKE_AUX are included through complex function. My concern is about which nonces are included in signature. From my recollection of SIGMA each party must sign (among other things, e.g. his MACed ID) his peer's nonce. I.e., initiator must sign responder's nonce and responder must sign initiator's nonce. With nonces exchanged in IKE_AUX this is not true, each party signs his own nonces sent in IKE_AUX, not peer's ones. So, the initiator still signs responder's nonce received in IKE_SA_INIT but signs only his own nonces that he sent in IKE_AUX exchanges (implicitly, by including AUX_I which is PRF over initiator's IKE_AUX messages). The same for responder. So my concern is - is it OK that each party only signs his peer's nonce from IKE_SA_NIT and doesn't sign his peer's nonces from IKE_AUX, signing his own nonces instead? > > My understanding is that the crypto world is now trying to migrate to > > quantum-safe crypto (including key exchange). > > The problem is that now we don't have quantum safe key exchange > > methods that are fully trusted by cryptographers and have acceptable > > performance and public key size. For that reason we want to bundle several > > key exchange methods and for this purpose we need to invent that things > > like IKE_AUX. But I hope that in a future cryptographers will eventually invent > > key exchange methods that will be fully trusted and have acceptable key > > size, and these methods will be so good, that can even replace classic (EC)DH. > > If that happen, all sophisticated games with IKE_AUX will become > > unnecessary and we can come back to a single key exchange in IKE_SA_INIT > > using these new methods... So I meant that only such methods should be > > added to Transform Type 4. > > Given that we don't know which such methods would eventually meet this final criteria of "usable only by > itself", I would expect that we would be well advised to include everything on the list. Even in cases of > methods with moderately large key shares (e.g. Frodo), there are times that IKE doesn't care about > fragmentation (e.g. TCP encaps), and in those cases, it might very well be considered a viable option by itself. OK, this makes sense. > In addition, you essentially gave two proposals; one where transform type 6 meant "Lattice Based", and > another proposal where transform type 6 meant "whatever key exchange we're doing in the first IKE AUX > exchange". > > Of those two proposals, I would personally vote for the second one; it would appear to me to be cleaner (of > course, I would still prefer the tjhai proposal to either...) The second one was my preference too. > > > Why not make them all a possible transform id for type 4? After all, > > > there are scenarios where fragmentation is not an issue (e.g. TCP > > > encaps) > > > > Since responder can return only a single transform of each type, this would > > mean that we cannot bundle several key exchanges unless new Transform > > Types are defined. > > > > Or do you mean that we still define new Transform Types, but make all new > > key exchanges available in Transform Type 4 too for the cases where > > fragmentation is not an issue and we don't need classic (EC)DH? > > The latter (still define new Transform Types, but also make all new key exchanges available); I see no specific > reason to restrict things unnecessarily... I agree. > > Using attributes will make definition of Transform ID clearer, but, as Tero > > pointed out, it won't help negotiation. > > But using attributes instead of defining a large number of Transform IDs for > > all possible combination of parameters looks like a good idea - at least we'll > > save a few bytes on the wire and a lot of lines on IANA registry page :-) > > Actually, I believe using attributes (rather than distinct transform ids) would add to the payload size (but only > slightly). For example, instead of: > > +-- Transform D-H ( Name = NTRU_3 ) > > We might have > > +-- Transform D-H ( Name = NTRU ) > +-- Attribute ( Security Level = 3 ) It seems that you are right here and I was wrong. I was thinking of situation when attributes can define ranges, in which case we could save some space in some situations, but it is not possible now. > > Do I get you right that the idea is to negotiate several successive SAs with > > unmodified CREATE_CHILD_SA, each with different (QS)KE methods, so that > > the resulting SA absorbs entropy from all the exchanges? > > That could work for IKE SA (rekeying), but I fail to understand how it will work > > for Child SAs. If you want to create new or rekey existing Child SA with > > additional entropy, then you cannot perform successive key exchanges > > unless you somehow modify CREATE_CHILD_SA exchange. Did I miss > > something? > > Actually, the original idea was cruder than that; suppose you wanted to rekey an IPsec SA, and you used three > key exchange methods. What you would do is: > > - First create a child IKE SA (using keying mechanism 1); this would replace the original IKE SA > - Then, create a second child IKE SA (using keying mechanism 2); this would replace IKE SA that you just > created > - Finally, create children IPsec SAs (using keying mechanism 3) > > As I said earlier, I could certainly understand it if the WG decided that this was unacceptable... Well, this essentially means that any need to create or rekey Child SA with additional entropy will require several successive rekeys of IKE SA. How policy will be negotiated in this case? In IKE_SA_INIT initiator proposes all KE methods at once and responder selects an appropriate combination. In your proposal initiator proposes them one by one, so that responder don't have whole picture. You can argue, that policy should non change in case of rekey, but if you create a new Child SA for with different selectors you would probably want to create it with different policy, than IKE SA and previous Child SAs... I also suspect some complications with simultaneous rekeying... Regards, Valery. From nobody Fri Nov 2 01:57:27 2018 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 5F5CE12D4F2; Fri, 2 Nov 2018 01:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 dqFpAnrk-Vk9; Fri, 2 Nov 2018 01:57:24 -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 147C91277CC; Fri, 2 Nov 2018 01:57:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42mbYY3n1PzFcG; Fri, 2 Nov 2018 09:57:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1541149041; bh=po6cx9dn/3rq23JZHFdZRdG6UQp4U4eOyx4lF2sa//Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DhjkVSnfdjV6sY1KjrBQxmWUNIBxQ8Dw5e001c9A5tcTaqXm6bo4VVAuQHxNJ+Rdv 5b1Z83+K/OvWisyr6XdtKHkjoxCsYLd4hmTlQ/Qc/IrK2twascEbZrGFdlc7jAaDvR REb527Ahrv5tpjdpu/6RLKH4uMndHGb7BykJIfkY= 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 oE09hrrEwJfT; Fri, 2 Nov 2018 09:57:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 2 Nov 2018 09:57:20 +0100 (CET) Received: from [IPv6:2001:44c8:44d0:7502:44d8:4b32:238b:9311] (unknown [182.232.245.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id BB5D24E18C3; Fri, 2 Nov 2018 04:57:18 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BB5D24E18C3 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: <23514.13527.860102.126373@fireball.acr.fi> Date: Fri, 2 Nov 2018 15:57:15 +0700 Cc: "Scott Fluhrer (sfluhrer)" , IPsecME WG , Valery Smyslov , "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8D1D0811-DB80-4151-842C-2746910672E6@nohats.ca> References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> To: Tero Kivinen Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 08:57:26 -0000 > On Nov 1, 2018, at 06:03, Tero Kivinen wrote: >=20 > Scott Fluhrer (sfluhrer) writes: >> My issue with this general idea is backwards compatibility; if we >> issue a transform of type 5 to an old IKEv2 system, it may reject >> the entire exchange with an "unrecognized transform type" error (and >> yes, there are real systems that behave this way). >=20 > That implementation is broken, and needs to be fixed.=20 Indeed, the WG repeatedly said this is not a valid argument. Let=E2=80=99s b= ury it for good this time. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. >=20 > In section 3.3.6 this is explained very clearly: >=20 > If the responder receives a proposal that contains a Transform Type > it does not understand, or a proposal that is missing a mandatory > Transform Type, it MUST consider this proposal unacceptable; however, > other proposals in the same SA payload are processed as usual. > Similarly, if the responder receives a transform that it does not > understand, or one that contains a Transform Attribute it does not > understand, it MUST consider this transform unacceptable; other > transforms with the same Transform Type are processed as usual. This > allows new Transform Types and Transform Attributes to be defined in > the future Agreed. Paul= From nobody Fri Nov 2 09:09:11 2018 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 93B9712D4E6; Fri, 2 Nov 2018 09:09:10 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 s3rjmc0wmmbx; Fri, 2 Nov 2018 09:09:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C3012872C; Fri, 2 Nov 2018 09:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2938; q=dns/txt; s=iport; t=1541174948; x=1542384548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FbdsBrSTfUGEBZ70zXOGCWXQcu+quZIUuKTy0wp6Dxc=; b=mYRlph3iVSE+xGwyKqjz7GcFQ7GF/xPADN1DNKa/X54+9w2Rzalsn5Ez y3W52GF6kjdxzbclndTgW5EklLE0imRwoegsg2j1p3IGiZqzEcdM/SOL0 2j8OmbVY/YwsLGlFx/JdAUOH5Z6UoTtfS3VfuZ3HgRAREt8NsYI9hWR9l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAOdtxb/5NdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBggSBZSgKmBqCDYkCjiqBegsBAYRsAoM?= =?us-ascii?q?+IjUMDQEDAQECAQECbSiFOgEBAQEDOj8MBAIBCBEEAQEfECERHQgBAQQBDQU?= =?us-ascii?q?IhQMDFahgh3sNghiKVIEdF4FBP4EQgxOCVoJOhTUCiGSWGC4JAo1ggyIgkFu?= =?us-ascii?q?OCIkPAhEUgSYfAzOBVXAVgyeCJRiOGm+MKIEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,456,1534809600"; d="scan'208";a="195589730" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 16:09:07 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wA2G96Hk008899 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 16:09:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 2 Nov 2018 12:09:03 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1395.000; Fri, 2 Nov 2018 12:09:03 -0400 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "'IPsecME WG'" CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 Thread-Index: AdRxISFkud4inQZOTYCMbnQCiNECBQABjTEgADOL0QAAAcPNMAAqktyAAAeJvQA= Date: Fri, 2 Nov 2018 16:09:03 +0000 Message-ID: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> <086b01d47285$5a161340$0e4239c0$@gmail.com> In-Reply-To: <086b01d47285$5a161340$0e4239c0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.150, xch-rtp-010.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 16:09:10 -0000 > -----Original Message----- > From: Valery Smyslov > Sent: Friday, November 02, 2018 4:24 AM > To: Scott Fluhrer (sfluhrer) ; 'IPsecME WG' > > Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > Subject: RE: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 >=20 > > > It's true that AUX_I (f collision resistant PRF of initiator's > > > IKE_AUX messages) is included in the initiator's signature. > > > My concern is: from my recollection of SIGMA paper it is essential > > > for security that each party includes its peer's nonce in the > > > signature. In case of IKE initiator, the NonceRData is responder's > > > nonce (from IKE_SA_INIT) and it is included. > > > But the AUX_I contains only PRF over initiator's messages, i.e. it > > > contains only initiator's additional nonces, not responder's ones. > > > Is it OK for authentication that we don't include peer's additional > > > nonces in the signature? Won't we screw up SIGMA? > > > (Disclaimer: I'm not a cryptographer). > > > > The nonces are included; however instead of including the text of the > > nonce directly, we're including a complex function of (among other > > things) the nonces. If you change the nonces, you change the output of > that complex function, which changes the text of what is signed, and that= is > what SIGMA relies on. >=20 > Sorry for being tedious, I just want to eliminate all possible > misunderstanding. >=20 > I understand that the nonces exchanged in IKE_AUX are included through > complex function. > My concern is about which nonces are included in signature. From my > recollection of SIGMA each party must sign (among other things, e.g. his > MACed ID) his peer's nonce. I.e., initiator must sign responder's nonce a= nd > responder must sign initiator's nonce. > With nonces exchanged in IKE_AUX this is not true, each party signs his o= wn > nonces sent in IKE_AUX, not peer's ones. So, the initiator still signs > responder's nonce received in IKE_SA_INIT but signs only his own nonces > that he sent in IKE_AUX exchanges (implicitly, by including AUX_I which i= s > PRF over initiator's IKE_AUX messages). The same for responder. Hmmmm, reviewing your draft, I see your point. I had assumed that both sid= es signed a hash of the entire AUX transcript; I now see that both sides si= gn only what they sent. Sigma has both sides sign the other side's nonces to avoid potential replay= attacks (where the adversary replays a previously recorded signature). This may be a concern in our case; the first obvious thing to do would be t= o modify the AUX draft to have both sides sign everything. So, we would have (in terms of your draft): AUX_I =3D [AUX_PRF_I_1 | AUX_PRF_R_1 [ | AUX_PRF_I_2 | AUX_PRF_R_2 [ ... ] = ] ] (and AUX_R could be exactly the same) Does this sound reasonable? From nobody Sat Nov 3 06:41:15 2018 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 D9999128CB7; Sat, 3 Nov 2018 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, 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 rmzysTRA5KtK; Sat, 3 Nov 2018 06:41:12 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 A6A9A1277D2; Sat, 3 Nov 2018 06:41:12 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id k1-v6so2211008pgq.1; Sat, 03 Nov 2018 06:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=A4OierYOlWQFZ8mWUQr/VF6DTZf+lNaP3Lm6sNvf1ok=; b=SO0Dvf9u6bGL/X6IvkCA1eNIjsoM7LKrxYBstzxXLI7stqlE0dU4Pm/Fbxwll+RBJQ i3K3gvXMgbbjMZHD193GT9391ZUZqyfKePF5uEvzZgpl00IEPVrcTO7S+MxVlL43jkjW l8d5DnrxuTXeOVawxAU0GNTjqgbq3K6XWc/fuWZeag+dVTdUWr2mwJeun+3KkuIAmwHV mIJXVzf/0TuDR/DHN//uMkbbn+tiDIrM8P5ylih6UvoqnunxY61jUQUofps21ed4QPrX WGUHQEPBM/i5kqM8Xxz1BSuqilsqCIvijqDFW6WITjrR9LX8U2r4nLvd1SE//Frs+ayv 0+zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=A4OierYOlWQFZ8mWUQr/VF6DTZf+lNaP3Lm6sNvf1ok=; b=CEJBWBubAUJYoK1j135dqMZND4G65A8JRcSGCYdX6DETIZM9Kfz1dXiIu/8DG/T/HG IhezmcYS5wnLH4n12sgLZavICVWfdAF3jvMRm5RNuIFYtI+rnSI0s54JivfSM6DsudYP pGbl2Pum/HLljxmyVQde+SNP9hsXV9CGo6SXqW513Wd3hpwS8YAobXKn7zJTH7zuhxMo cRS1ebUFh7EzzltF7wlSn5FRHWXHOMIvHheGVOMQmI1L+pZj5xp/44D23AEfDNo22Dop cm7SaWVDJE3tqosSV7CakzhFS7WaYbKtoEvplBHeb3nuANnQebOpdbjJD2u+OdTrAL0P GA0Q== X-Gm-Message-State: AGRZ1gIpBbqXGHNzLCxHoAzSfJGrXCt+RZG5A124wj2U52z0xnToc06M mDpIuQTf0hS4NN7iMW+e6nMIL6z+wXo= X-Google-Smtp-Source: AJdET5cnAIEVFifPEzKpb8F6CkJ69ev6DbxnKezkpP3Q2u5NCpGhBXqIG04YBWQQgjoUxfr+V7ECKw== X-Received: by 2002:a63:da14:: with SMTP id c20mr13796881pgh.233.1541252471627; Sat, 03 Nov 2018 06:41:11 -0700 (PDT) Received: from svannotebook ([58.64.7.19]) by smtp.gmail.com with ESMTPSA id s2-v6sm40108143pgo.90.2018.11.03.06.41.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 06:41:10 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'IPsecME WG'" Cc: References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <07c001d471d3$ff2a08d0$fd7e1a70$@gmail.com> <086b01d47285$5a161340$0e4239c0$@gmail.com> In-Reply-To: Date: Sat, 3 Nov 2018 20:41:07 +0700 Message-ID: <000001d4737a$e14f1e10$a3ed5a30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQBiexsmH6yYgnMQDSohT/oic8CpEgFU4nhiAfgiA5cC+Fx/KQGTU3NBAqMxyV6nzhmIgA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 13:41:14 -0000 > > I understand that the nonces exchanged in IKE_AUX are included through > > complex function. > > My concern is about which nonces are included in signature. From my > > recollection of SIGMA each party must sign (among other things, e.g. > > his MACed ID) his peer's nonce. I.e., initiator must sign responder's > > nonce and responder must sign initiator's nonce. > > With nonces exchanged in IKE_AUX this is not true, each party signs > > his own nonces sent in IKE_AUX, not peer's ones. So, the initiator > > still signs responder's nonce received in IKE_SA_INIT but signs only > > his own nonces that he sent in IKE_AUX exchanges (implicitly, by > > including AUX_I which is PRF over initiator's IKE_AUX messages). The same > for responder. > > Hmmmm, reviewing your draft, I see your point. I had assumed that both > sides signed a hash of the entire AUX transcript; I now see that both sides sign > only what they sent. Yes, that was inspired by the current IKE authentication scheme, when initiator includes only his IKE_SA_INIT message into the signature and separately includes responder's nonce (and of course initiator's MACed ID). Ditto for responder. Following this logic I added only each party relevant IKE_AUX messages (thinking of IKE_AUX as of extended IKE_SA_INIT) into their signatures. Note, that at that time no additional nonces were exchanged in IKE_AUX. > Sigma has both sides sign the other side's nonces to avoid potential replay > attacks (where the adversary replays a previously recorded signature). > > This may be a concern in our case; the first obvious thing to do would be to > modify the AUX draft to have both sides sign everything. > > So, we would have (in terms of your draft): > > AUX_I = [AUX_PRF_I_1 | AUX_PRF_R_1 [ | AUX_PRF_I_2 | AUX_PRF_R_2 [ ... ] ] > ] > > (and AUX_R could be exactly the same) > > Does this sound reasonable? II believe yes. And I have no problem with this from implementer's point of view. Regards, Valery. From nobody Sat Nov 3 20:12:11 2018 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 727F0128B14; Sat, 3 Nov 2018 20:12:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154130112943.10188.3089070628520110857@ietfa.amsl.com> Date: Sat, 03 Nov 2018 20:12:09 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 03:12:10 -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 WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-14.txt Pages : 13 Date : 2018-11-03 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-14 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 Sun Nov 4 09:05:13 2018 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 523A712D4EA; Sun, 4 Nov 2018 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 MoHubzX1NlUB; Sun, 4 Nov 2018 09:05:10 -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 5C4BF129385; Sun, 4 Nov 2018 09:05:10 -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 wA4H4k0f002720 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Nov 2018 19:04:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wA4H4ke4004455; Sun, 4 Nov 2018 19:04:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23519.9902.677887.857534@fireball.acr.fi> Date: Sun, 4 Nov 2018 19:04:46 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: Valery Smyslov , IPsecME WG , "draft-tjhai-ipsecme-hybrid-qske-ikev2\@ietf.org" In-Reply-To: <9313650867b44edc82256265e29d7dbb@XCH-RTP-006.cisco.com> References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> <23514.13527.860102.126373@fireball.acr.fi> <9313650867b44edc82256265e29d7dbb@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 18 min Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 17:05:12 -0000 Scott Fluhrer (sfluhrer) writes: > > That implementation is broken, and needs to be fixed. > > I can easily see a manufacturer claiming "my implementation has been > working without a problem for 13 years; why does it need to be > fixed?" And the answer will be: Because it is broken, and it is not following what RFC says. Even if this issue was not found before as this feature was not used, this does not mean that their implementation would be less broken. And if any vendor says that they have not done any single security fix for their implementation for last 13 years, it is time to switch vendors. > Ultimately, it's the working group that needs to decide whether we > need to respect the (to the implementors) apparently valid > assumption as de facto, or whether we feel we can break them. We had same issue earlier. I.e., several implementations did assume that we never need mor than one proposal, as there is never need to support policies that would require more than one proposal. I.e., they did not support policies which said 3DES + MD5 or AES + SHA1, but which forbid 3DES + SHA1 and AES + MD5. This would have required two proposals, and as those kind of policies are stupid, some implementations (like mine) did not support them. When we defined combined mode ciphers, we decided that you need to do that with two proposals, one having non-combined mode ciphers and other having only combined mode ciphers. All implementations wanting to support combined mode ciphers, needed to include support for at least two proposals if they wanted to allow policies that allow both. To support backwards compability implementations can put the non-combined mode ciphers in first proposal, so if other end only parses first proposal, it will find the find the acceptable proposal from there. Those old implementations did not support combined mode ciphers anyways. We can do same here. Put traditional DH version in first proposal, and they will most likely pick that... Or you can put vendor ID check and return error "Other end is using obsolete implementation of the IKEv2, please upgrade it immediately as those kind of implementations not receiving updates are most likely vulnerable to all kind of attacks. Are you sure you really still want to connect using compatibility mode?" -- kivinen@iki.fi From nobody Mon Nov 5 01:32:56 2018 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 DE3C41277BB; Mon, 5 Nov 2018 01:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154141037488.9296.5355775816536296493@ietfa.amsl.com> Date: Mon, 05 Nov 2018 01:32:54 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:32:55 -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 WG of the IETF. Title : IKEv2 Notification Status Types for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-01.txt Pages : 6 Date : 2018-11-05 Abstract: This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ipv6-ipv4-codes-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 5 08:01:14 2018 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 56E78130E8B for ; Mon, 5 Nov 2018 08:01:09 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Wst4z5BB4z9J for ; Mon, 5 Nov 2018 08:01:06 -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 7CCFD130E73 for ; Mon, 5 Nov 2018 08:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3514; q=dns/txt; s=iport; t=1541433666; x=1542643266; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lUwpQm0kRY+l7JTHH08k/6UvWti76+8d7wfTK3gqJVs=; b=McjIHj6yrH3vsNWeKixtfZqGaI3TdeTXajTeVQOEp1NCE1VLRZHZFmGH He5DdMMxjw6v0ylw1jwvkC4RtkrjNTq/WcpAULDyIWAZhmdiys6yDxPff 3JUqyZj/xWEzTKGqbyg7Rt15vmGNIQNME4B29lz2tm2hZx28GX61Kg3UL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAABEaOBb/5tdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCBGZ/KAqYG4INmScLAQEbhFECg1EiNwoNAQM?= =?us-ascii?q?BAQIBAQJtHAyFOgEBAQEDOiwfBAIBCBEEAQEfEDIdCAEBBAESCIMaggGqEYo?= =?us-ascii?q?ai3YXgUE/gRABgxKFJIU1AohklXpUCQKGbIMkhncggVVMhDSKC4ZBgwGNXQI?= =?us-ascii?q?RFIEmMyKBVXAVO4JsCYIeF4J1gVWJUW+NA4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,468,1534809600"; d="scan'208";a="474786941" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 16:01:05 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wA5G146T009433 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Nov 2018 16:01:05 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 10:01:03 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Mon, 5 Nov 2018 10:01:03 -0600 From: "Panos Kampanakis (pkampana)" To: "Hammell, Jonathan F" , "'ipsec@ietf.org'" Thread-Topic: Verification of IKEv2 PPK Thread-Index: AdRyEdEAKPTdpk+ASB+1RAcLuzulbgDC/4sA Date: Mon, 5 Nov 2018 16:01:03 +0000 Message-ID: References: <20181101184231.7F928124BAA@ietfa.amsl.com> In-Reply-To: <20181101184231.7F928124BAA@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.217.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [IPsec] Verification of IKEv2 PPK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 16:01:13 -0000 Hi Hammell, This is interesting. Thank you for doing this work to systematically confir= m the logic and the state machine of the protocol update.=20 You assumptions are correct.=20 - The Have_PPK indeed means we have a PPK configured for the PPK_ID sent in= the initiator's notification. - The PPK Mandatory indeed is there to prevent downgrades when configured b= ut also allow for backwards compatibility when disabled. Rgs, Panos -----Original Message----- From: IPsec On Behalf Of Hammell, Jonathan F Sent: Thursday, November 01, 2018 2:43 PM To: 'ipsec@ietf.org' Subject: [IPsec] Verification of IKEv2 PPK Classification: UNCLASSIFIED Researchers at the Canadian Centre for Cyber Security (CCCS) have modeled t= he state machine of the IKEv2 PPK I-D draft-ietf-ipsecme-qr-ikev2-04 in ord= er to verify the logic. =20 The attached file qr_ppk_responder.smv contains a model written for NuSMV (= http://nusmv.fbk.eu) of an asynchronous finite-state machine modelling the = responder role described in the I-D. The file also contains CTL specificati= ons of the 7 conditions presented in the table on page 8 of the draft. To run, please install a recent version of NuSMV and run the command ./NuSMV qr_ppk_responder.smv The output shows the results of the application of the CTL specifications t= o the model.=20 We also include several CTL sanity checks for the model, but they are curre= ntly disabled in order to be clear about the claims. Comments about the implementation of the draft: The table on page 8 was found to be essential in developing a working model= .. Several of the table conditions needed some interpretation and we hope o= urs is correct. "Have PPK" =20 Our interpretation was that "Have PPK" specifies whether a Responder shared= a valid PPK with an Initiator. We noted that in order for determination to= be made whether he did nor not, the Responder would first need to receive = an ID either in the PPK_IDENTITY notification or from the IDi payload (if c= onfigured to do so), and then check whether the ID was known and if it was = whether or not a PPK was configured for this ID.=20 In our implementation for example, we modelled that a Responder shared a PP= K with the initiator with the condition: NOTIFY.PPK_ID =3D TRUE & VERIFY.PPK_ID_KNOWN =3DTRUE=20 Which states that a PPK_ID notify was received and that the ID from the not= ify was known=20 Equivalently he could use the ID from the Idi payload if configured appropr= iately, which is expressed as follows NOTIFY.PPK_ID =3D TRUE & VERIFY.PPK_ID_KNOWN =3D FALSE & VERIFY.PAYLOAD_ID= _KNOWN =3D TRUE & CONFIG.USE_ID_PAYLOAD =3D TRUE=20 In both cases after a successful ID check, they will then check whether the= y actually share a PPK i.e VERIFY.HAVE_PPK =3D TRUE "PPK Mandatory" Our interpretation is that PPK Mandatory limits successful completion of th= e handshake to cases where the parties share a PPK, in this case no downgra= de is possible.=20 The check occurs after a successful ID check and at the same time as the ch= eck to see if they share a PPK. If it is mandatory, the only non-error path= is when they share a PPK. CONFIG.PPK_MANDATORY =3D TRUE & VERIFY.HAVE_PPK =3D TRUE If you have comments/questions, reply to the list or we can chat in Bangkok= .. Jonathan Hammell Canadian Centre for Cyber Security https://cyber.gc.ca From nobody Tue Nov 6 20:38:34 2018 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 3C937130EA3 for ; Tue, 6 Nov 2018 20:38:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YXdXza-cESsW for ; Tue, 6 Nov 2018 20:38:21 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 352CA130EF1 for ; Tue, 6 Nov 2018 20:38:19 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id z10so4940253pgp.7 for ; Tue, 06 Nov 2018 20:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=CyVKNB0yajTC4Vg+4UVY6yIu/zBUpcS5WRKuYWsYsfk=; b=FJSUAjQ+qbzSHqC/C7U6h2rJxTc2ct0MalgMkrK5JTNa34zRBil3jRDOlkOuR8R9rd VyXle3Sndx62BnBWNey8V94cgj2Q+AdQrcDHlEdAjq8WxYxI71OkxVn3EaBFgrmKFAQ+ NqpQzBEGLDWEaOO8/fHx1CQYpJf5oHPa8+PW/q8FTlarKA2I1tDm5Nc2FhfBnb/RNAW8 80hsjQROc6M9MG2GluBvIrPy9qo7c5dBpfXxNXjj1N3HRuj/DEv+dLTFPj54tfI+ODQF MTHjhYo5O8B6u6yyA05rtQP/CPzns3iN5pgR0nuiN5bPQh8BIgZ9iIiCfW4kWrDS/ImG RNRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=CyVKNB0yajTC4Vg+4UVY6yIu/zBUpcS5WRKuYWsYsfk=; b=YYY6AbMQUlotCmtlwaafJ9LQmBRXR4Gj9jVsvZLqqJ7xPCTIB68wI6auOx/x6+5Xn7 XSqarsI44kKhpnodG/3+ZiL+OxBC/YPFcZtvfilOPQEROHMfTRkS8N/zDKR+bIIVi6Rt nY6q4nN5M6Jh9EpZ3DEl9k1ohHeMMq2SDQmqU/AEinJta7HxFCxQtZ688Pl3QHYMZbCl Nhwaxf0tsOARskiTob7MtmhbuX1ddCY5/qlww0oY0mWKEBA5E3nOyuqbAEBEAJW7Ih6H jAeDdGar07KZzpcWZMR55VZu08U/yYQT0HQfIx4GN+iXTAc8ao2NPSYkh2yVjNqXXtXu URMw== X-Gm-Message-State: AGRZ1gLvc9c41suqrgbJbpSgXKbELyGa51nctRByVyN4V2BVI8BXeA50 3+i/eMpDbeQ2wjWDFF80X3wtmfIV X-Google-Smtp-Source: AJdET5dJPmvDtp6aS1fjt5PH1PFQnHTcY9cRu2AOYDSxIu5yN4ztvRbZnoSxDYctwGQTyCNmxgiWpw== X-Received: by 2002:a63:ec12:: with SMTP id j18mr372784pgh.200.1541565498434; Tue, 06 Nov 2018 20:38:18 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:5082:4096:1354:4285? ([2001:67c:370:128:5082:4096:1354:4285]) by smtp.gmail.com with ESMTPSA id s86-v6sm3295109pfa.137.2018.11.06.20.38.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 20:38:17 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_7D4F64AF-DC77-4527-B5C9-483920111DAE" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: Date: Wed, 7 Nov 2018 11:38:14 +0700 Cc: Linda Dunbar To: IPsecME WG X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: [IPsec] Heads Up: I2NSF Meeting Today X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 04:38:27 -0000 --Apple-Mail=_7D4F64AF-DC77-4527-B5C9-483920111DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all FYI: The I2NSF working group is meeting today immediately after IPsecME = and in the same room (convenient!) We are going to spend some time on SDN-based IPsec Flow Protection [1]. = We have had some discussion in the past about Case #2, which is about = provisioning traffic keys (in the form of IPsec SAs) from an SDN = controller to the NSF (which is I2NSF-speak for, among others, an IPsec = host/gateway). There were some objections and we would like to bring = that discussion to a close. For your convenience, this part is the first thing on our agenda. You = are all invited. As a heads-up, we will also be looking for a volunteer to help with = review of this document, especially with pruning some of the YANG stuff = in Appendix A ([2]). It=E2=80=99s been suggested that 2018 is the wrong = year to publish a way to configure IPsec gateways to use DES. Or KINK. Hope to see you all there, Linda & Yoav [1] = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 = [2] = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03#= appendix-A = --Apple-Mail=_7D4F64AF-DC77-4527-B5C9-483920111DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all

FYI: The I2NSF = working group is meeting today immediately after IPsecME and in the same = room (convenient!)

We are going to spend some time on SDN-based IPsec Flow = Protection [1].  We have had some discussion in the past about Case = #2, which is about provisioning traffic keys (in the form of IPsec SAs) = from an SDN controller to the NSF (which is I2NSF-speak for, among = others, an IPsec host/gateway). There were some objections and we would = like to bring that discussion to a close.

For your convenience, this part is the = first thing on our agenda.  You are all invited.

As a heads-up, we will = also be looking for a volunteer to help with review of this document, = especially with pruning some of the YANG stuff in Appendix A ([2]). = It=E2=80=99s been suggested that 2018 is the wrong year to publish a way = to configure IPsec gateways to use DES.  Or KINK.

Hope to see you all = there,

Linda = & Yoav

[1] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-03
[2] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-pro= tection-03#appendix-A

= --Apple-Mail=_7D4F64AF-DC77-4527-B5C9-483920111DAE-- From nobody Wed Nov 7 01:51:23 2018 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 67DC6130E36 for ; Wed, 7 Nov 2018 01:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 7eMff7VALdWG for ; Wed, 7 Nov 2018 01:51:15 -0800 (PST) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 64460130DF6 for ; Wed, 7 Nov 2018 01:51:15 -0800 (PST) Received: by mail-lj1-f170.google.com with SMTP id v15-v6so5539286ljh.13 for ; Wed, 07 Nov 2018 01:51:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ifGVumu9hk0OdiF7KT1xOCGEDPfUDQoduRET/igjHyk=; b=TzP5l5ZfSucXHYB1uJ1o95zIfR/4Pk1XkNnY4TxpsJHAcEHBdQc4+UKjwFLKLpaTc1 zQxktmxI1ClbFx07gxIodZJlsFahqK/xF9H+dYOMvmHp6DXAmIz1ueS0rWZqVsZUL9lZ 9YH4LCwA0MkBIz6giIVugMe1BJYCk8jMHU6Mqvb0kODvvCj0Z7J1uvF3ZB/vxerWxrWw 7vP+H6+FEn77dJP/nXSE8zFWo3E8i2bvIAJkJ7yNPozbSk1uH8FvESgEVaRWjtEFrpkm HkoB/ukNgewh06AB8LA5Q3E4HHGe021kGeoW2S73b9hS3M6SAlSn4etwZpqkSiJk0OMU 1dsw== X-Gm-Message-State: AGRZ1gJXnHREMfLgvlUbU/1N45CnqR0YhsM5BpljAi8nVEKrQk1Jwg0s kt4XV23vGOxpzJWImSnsgL8et5oDIaHZEzUVuITv3/jY X-Google-Smtp-Source: AJdET5exH9OM/HCgf0BUdMC0L4UFy+Pum4eVPEVyxFx63Ilqzu9hRCZqCRvyd3dEdXjE6ZOq5m7wtG1NcDj4jk/Lbog= X-Received: by 2002:a2e:9059:: with SMTP id n25-v6mr816907ljg.155.1541584272871; Wed, 07 Nov 2018 01:51:12 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 7 Nov 2018 04:51:01 -0500 Message-ID: To: IPsecME WG Content-Type: multipart/alternative; boundary="000000000000f9d381057a100eb4" Archived-At: Subject: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 09:51:21 -0000 --000000000000f9d381057a100eb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, One of the comment was the number of AF failure error. I think Med already answered this comment [1], see the question/answer below. If that does not address the question raised today, please describe how the number could be reduced. Please also state whether we should use one status code for all AF failure error versus one status code per AF failure error. I think the WG preferred the latest alternative. Yours Daniel [1] https://mailarchive.ietf.org/arch/msg/ipsec/3DM_MzLmG-JYKGbA15siCkJbqV8 """ * Looking at the code points, I have the impression that with the current signaling, only the case where a single af is supported could be ambiguous. A host sending a request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported. [Med] There are cases where both AFs are supported, but only an address/prefix can be returned. Which address is returned is policy-based. An initiator which does not get an address family type does not know whether it didn=E2=80=99t get the requested AF because (1) it is not suppor= ted or (2) because of a policy. The behavior of the initiator may change as function of this. For example, if it really needs an IPv4, but gets an IPv6 prefix, it will need to issue a request in which only INTERNAL_IP4_ADDRESS will be included and so on. """ --000000000000f9d381057a100eb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On= e of the comment was the number of AF failure error. I think Med already an= swered this comment [1], see the question/answer below. If that does not ad= dress the question raised today, please describe how the number could be re= duced.

Please also state whether we should use one= status code for all AF failure error versus one status code per AF failure= error. I think the WG preferred the latest alternative.

=
Yours
Daniel

* Looking at the code points, I have the impression that with the current signaling, only the case where a single af is=20 supported could be ambiguous. A host sending a request for IP4 and IP6=20 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported.

=C2=A0

[Med] There are cases where both AFs are supported, but only an=20 address/prefix can be returned. Which address is returned is=20 policy-based. An initiator which does not get an address family type does not know whether it didn=E2=80=99= t get the requested AF because (1) it is not supported or (2) because of a=20 policy. The behavior of the initiator may change as function of this. 

For example, if it really n=
eeds an IPv4, but gets an IPv6 prefix, it will need to issue a request in w=
hich only INTERNAL_IP4_ADDRESS will be included=
 and so on. =C2=A0=C2=A0<=
/span>

"""

--000000000000f9d381057a100eb4-- From nobody Wed Nov 7 03:18:00 2018 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 C67A7129BBF for ; Wed, 7 Nov 2018 03:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 0JH8QUb3wHLJ for ; Wed, 7 Nov 2018 03:17: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 19313128CF2 for ; Wed, 7 Nov 2018 03:17:55 -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 wA7BHrL2005825 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Nov 2018 13:17:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wA7BHrTC005556; Wed, 7 Nov 2018 13:17:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23522.51681.772148.523385@fireball.acr.fi> Date: Wed, 7 Nov 2018 13:17:53 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] Minutes from the IPsecME meeting in Bangkok IETF 103 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 11:17:59 -0000 Thanks for minutes takers for taking the minutes in the etherpad. I cleaned them up bit, and posted them to the meetings materials page: ---------------------------------------------------------------------- IETF 103 IPsecME WG meeting in Bangkok Wednesday, November 7, 2018 13:50-15:20 Boromphimarn 4 Agenda: - Agenda bashing, Logistics -- Chairs (5 min) - Draft status -- Chairs (15 min) - draft-ietf-ipsecme-eddsa -> RFC8420 - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - PSK authentication (10 min) Paul Wouters - IKE over TCP implementation issues (10 min) Valery Smyslov - draft-smyslov-ipsecme-tcp-guidelines - IPsec Compression mode for ESP (EHC) (15 min) - draft-mglt-ipsecme-ikev2-diet-esp-extension - IKEv2 Notification Codes for IPv4/IPv6 Coexistence (15 min) - draft-ietf-ipsecme-ipv6-ipv4-codes Agenda bashing, Logistics ========================= Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-chair-slides-02 agenda is bashed... Draft status ============ Tero: not a whole lot done since IETF 102 ("we have been lazy"). ECDSA draft is out as RFC 8420 Paul Wouters: split dns draft is on IESG telechat Tero: is the implicit IV draft ready? minor head nods not much discussion on QR IKEv2 draft. Valery Smyslov: it's ready, it's been ready since August. Paul: we've got interop testing done, it's more than ready Tero: still working on ipv6-ipv4 codes draft. Anyone else have a document you want to work on? Contact the chairs. PSK authentication ================== Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-psks-will-always-be-weak-00 Paul Wouters PSKs Will Always Be Weak New dictionary attacks on IKEv1 IKEv2 PSK mode is susceptible to dictionary attack. Information we give on use of PSKs is not really followed. PPK draft says use PSKs with 256 bits of entropy. But we know no one will do that. FIPS 198 and 198-1 has recommendations but what should we do? Users are not implementors and do not follow these recommendations. Main attack vector in IKEv2 is weak PSKs Do we need a new RFC to recommend minimum strength PSKs? This could cause implementations to do something. Dan Harkins: I like the title, yes they will always be weak. I'm not sure about an RFC to update this. I think the problem is that the protocol is weak, and the users must use a stronger key to avoid weak keys. We should use a PAKE, and write an RFC. Have a secure way to use PSKs. Yoav: You're saying we should obsolete PSK for something better? We don't have PAKE yet though. Easy to generate secure PSK. The problem is the inconvenience. Tero (as chair): PSKs are not meant to be readable by humans. Paul: problem is we punted this to users-- "don't do stupid things." Tero: if it's human readable then we need to use a secure PSK mode. Then mandate some size restrictions on PSKs. Stanislav: We should use a PAKE. CFRG is going to be discussing what PAKE to use. The way to address the problem you describe is to use a PAKE. Hu: We should not obsolete PSK, it's not going away. To make it secure we should use a PAKE. Valery: you can't stop users from doing stupid things. PAKE is a good option to use weak PSKs. But the framework doesn't make it easy to implement. State machine became more complex. But don't drop PSK mode. Sean Turner: we screwed the PAKE thing up the first time around but I'm not sure whether it would be fixed a second time. We have recommendations on PSK entropy and I would help to write a new one for IKEv2. Tero: The problem is that if we asked for doing one PAKE today, we would still not know what to do Stanislav: the CFRG process is just starting. There will be a process of identification, evaluation, and selection. Not sure of time frame but not years. Dan: we need a balanced PAKE because either side can initiate. Yaron Sheffer: we need a PAKE, we need a balanced PAKE. We should bring this input more formally into CFRG. Tero: we should ask CFRG to pick a balanced PAKE for us to use. ACTION ITEM FOR CHAIRS: send a note to the list on this and then forward request to CFRG. IKE over TCP implementation issues ================================== (draft-smyslov-ipsecme-tcp-guidelines) Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-clarifications-for-using-tcp-encapsulation-in-ikev2-00 Valery Smyslov Valery: TCP encapsulation is specified in RFC 8229. Need some optimizations though for reliability and interoperability. Should we do a RFC8229-bis to deal with all this? Yes, there are things to improve upon but none of these things are critical or showstopping. Tommy Pauly: On retransmissions: not sure why the congested issue is red. Tunneling ESP in TCP is a far greater concern for congestion than IKEv2. For cookie calculation, isn't that the same for UDP because you could be behind a NAT? Valery: yes but it's red because cookie calculation is a local matter. Paul: we have seen how NATs cause problems by rewriting the port number very quickly. Tommy: for MOBIKE, it should be identical to what you do over UDP. Valery: possibility of not detecting a NAT Tero: when you switch IP addresses in MOBIKE you can't recalculate. But when you update addresses, if they don't work change again and when the final one works then update. Should do same here. David Skenazii: what's the benefit of doing NAT detection in TCP? We can just throw the results on the floor. Valery: yes it's more tolerable. David: we can say if you use TCP then we can disregard any NAT detected. Paul: it's a little too soon to do a bis document, need a little more experience. Mark McFadden: Maybe instead of doing a bis just take this work, which is very good, and adopt it for implementation guidelines. Yoav: we can have a document that we work on but there's no rush to publish, it might become a bis eventually. Tero: we had a clarification document for IKEv2 but not sure how useful it was to publish. Could've just been a draft. We could do the same thing here. When we are ready we can work on a bis document. Opinions? Hums to work on it, no hums to not. Have to talk with ADs. IPsec Compression mode for ESP (EHC) ==================================== (draft-mglt-ipsecme-ikev2-diet-esp-extension) Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-esp-header-compression-ehc-00 Daniel Migault Valery: the idea to compress is exciting but it seems complex both in implementation and negotiation. Will not be easy to select all theose parameters. Is it possible to focus on the most effective options? Daniel: we took a long time defining the rules but the implementation should not be as long as the specification. Paul: you keep saying this is simple and straightforward but I read the draft and don't understand anything. There's a lot of complexity and IPsec and IKE are already compllicated. Yoav: how does this complain toe RFC 5756? Daniel: there is no down stream signaling. You have rules on each side. This is static, that is dynamic. David: yes this is simpler than that but battery powered devices are not just light switches, if we can improve lifetime of phones and watches there's value. IKEv2 Notification Codes for IPv4/IPv6 Coexistence ================================================== (draft-ietf-ipsecme-ipv6-ipv4-codes) Daniel Migault Valery: too many notifications for failures. In first case (slide 1), why not just say what you support (2nd and 3rd cases)? Tero: if you ask for both and you get back 1 you know. But SINGLE_AF_SUPPORTED does not help. Maybe reduce to 2. Lorenzo: These are 3GPP error codes, right? Is it harmful to do this? Daniel (continues with presentation, slide 2)... seems like there are some objections to assigning 4 new codes, should reduce it. Should we negotiate an extension? Tero: comments saying this should be simplified. Author wants to get draft out soon. Good to get them feedback. Open Discussion =============== we're done! -- kivinen@iki.fi From nobody Wed Nov 7 08:24:31 2018 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 8F4B312426A for ; Wed, 7 Nov 2018 08:24:30 -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=[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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, 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 QURY7msITMWX for ; Wed, 7 Nov 2018 08:24:28 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 CE80E1200D7 for ; Wed, 7 Nov 2018 08:24:28 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id i4-v6so7514388pgq.9 for ; Wed, 07 Nov 2018 08:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=hYWlUHNvSnuFEVF11wFh/RvuD652nyA7BwdA8XxrD9M=; b=Pj6aBH16wliBRT5GaEPTYezXzXliB3SUSITVGCDPT8kyHbvRNM+x9ULQ03dsUy6uCq x9iV/LGsZjqQ0B4yfa/+4RgWMRF6THs52jiMA0jS0xdoPkfVsj2QW/Kj1nlDed+i2XEK c9HxY/unaRSR2i1cDCc+KWDmOy03maj3lzvwnFl8XVXRvpKFXAbPoRrTq1hpZtWXfcu1 R3Lu5jHO2R7VrC+1yze7JUTv/X9v0MfmkaMTWhFC+KzBfIh81Qwata1SskjsT0Mg1AVt OzMZFQEgjuLgVPZEhmJcpA7zt+L49FKIIuCe0AUoNiJXHYjWoOxhGWot7I9aTkcqAZgW PuPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=hYWlUHNvSnuFEVF11wFh/RvuD652nyA7BwdA8XxrD9M=; b=pADe8Zjr1hFT/z+yLR7J0lb96zztVUI95PlLMWGrnlAjSHRBK7opcICylDH4kiPXjv 0lCmARFgvs6rxY+otQvPZGHlz+JLxo3HjI/K1eNBC4SX2r4ZwjPazA+BTcpnuqdHIFfb sEU6zoxhW4unCGcZHDQVwKDevfpXDvAr01zxVzyAXVDc1wmdyUijHHC1TRzgraVQHnb+ SMLwvnYM0d03EwgqGSrPeaFsoc0o/WL0XjA4KDP2A0rNTI328vuIjV/FLSPCg0unaVUD D8RyiOKrlLEV2+AaxItaiKzB7btlypf3Uc07wdJW/yBsD5d4Cd1Y25STb0qj3F8LGXMQ PaRw== X-Gm-Message-State: AGRZ1gJzRy9/jdgZvPTmHfuKUVSTH2teAzLesH/eoHzLXg3W8ZZLCmep fP+V+FfvnyY5F389Puzg9L0= X-Google-Smtp-Source: AJdET5eFrtxqwP01I4/AaXG6WHIKzWeJ0Y136i433yI7BADZPYs0quBQT9fNOYlYZcUpCRaaFq+8YQ== X-Received: by 2002:a63:d547:: with SMTP id v7mr701271pgi.339.1541607867953; Wed, 07 Nov 2018 08:24:27 -0800 (PST) Received: from svannotebook ([58.64.7.19]) by smtp.gmail.com with ESMTPSA id b14-v6sm1135006pgn.49.2018.11.07.08.24.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 08:24:27 -0800 (PST) From: "Valery Smyslov" To: "'Daniel Migault'" , "'IPsecME WG'" References: In-Reply-To: Date: Wed, 7 Nov 2018 23:24:21 +0700 Message-ID: <028001d476b6$59e19b30$0da4d190$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01D476F1.064220E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLdauT/kLgg+2bY81PWCwSLVlFbzqMyjojA Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 16:24:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0281_01D476F1.064220E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 it was me who made this comment. The current number of notifications = seems to be excessive for the task. Not that I'm all that greedy (also Occam razor has been = sitting sitting in my mind),=20 but the current design makes implementation more complex then it could = be. =20 You have a separate notification for each possible situation. That makes = the responder think before returning back a "proper" answer. But actually, most of = these different notifications return exactly the same two bit of information - which = address families are supported=20 by the server (or allowed by its policy). Moreover, this two bits of = information are mostly static!=20 =20 So, what design I would have preferred? Two notifications are enough - = SUPPORTED_AF (containing some data indicating which AFs are supported) and SINGLE_AF_SUPPORTED. = If you don't like notification data, then three notifications are enough - = IP4_AF_SUPPORTED, IP6_AF_SUPPORTED and SINGLE_AF_SUPPORTED. Note that I changed meaning from negative to = positive, that is=20 more appropriate for status type notification and also makes it possible = to easy extend=20 protocol in case a new fictional AF appears in future. =20 In this case the server can make an assignment of the IP addresses = decoupled from the returned notifications, which in this case become almost static: you = can _always_ return corresponding IP*_AF_SUPPORTED (either one of them or both) = regardless of whether you assigned IPs or not and which AF you assigned. That makes server = implementation simpler.=20 The only case when server need to return more is the 4th case, when it = would in addition send=20 SINGLE_AF_SUPPORTED (actually it is not all that needed and the client = can easily deduce it,=20 but let's make his life simpler). =20 This is mostly ad hoc design, it can definitely be discussed. =20 Regards, Valery. =20 =20 Hi,=20 =20 One of the comment was the number of AF failure error. I think Med = already answered this comment [1], see the question/answer below. If = that does not address the question raised today, please describe how the = number could be reduced. =20 Please also state whether we should use one status code for all AF = failure error versus one status code per AF failure error. I think the = WG preferred the latest alternative. =20 Yours=20 Daniel =20 [1] = https://mailarchive.ietf.org/arch/msg/ipsec/3DM_MzLmG-JYKGbA15siCkJbqV8 """ * Looking at the code points, I have the impression that with the = current signaling, only the case where a single af is supported could be = ambiguous. A host sending a request for IP4 and IP6 addresses, can = easily deduce is which are the supported AF, except when the a single AF = is supported.=20 =20 [Med] There are cases where both AFs are supported, but only an = address/prefix can be returned. Which address is returned is = policy-based. An initiator which does not get an address family type = does not know whether it didn=E2=80=99t get the requested AF because (1) = it is not supported or (2) because of a policy. The behavior of the = initiator may change as function of this.=20 For example, if it really needs an IPv4, but gets an IPv6 prefix, it = will need to issue a request in which only INTERNAL_IP4_ADDRESS will be = included and so on. =20 """=20 ------=_NextPart_000_0281_01D476F1.064220E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Daniel,

 

it was me who made = this comment. The current number of notifications seems to be excessive = for

the task. Not that = I'm all that greedy (also Occam razor has been sitting sitting in my = mind),

but the current = design makes implementation more complex then it could = be.

 

You have a = separate notification for each possible situation. That makes the = responder

think before = returning back a "proper" answer. But actually, most of these = different

notifications = return exactly the same two bit of information - which address families = are supported

by = the server (or allowed by its policy). Moreover, this two bits of = information are mostly static!

 

So, what design I = would have preferred? Two notifications are enough - SUPPORTED_AF = (containing

some data = indicating which AFs are supported) and SINGLE_AF_SUPPORTED. If you = don't like

notification data, = then three notifications are enough - IP4_AF_SUPPORTED, = IP6_AF_SUPPORTED

and = SINGLE_AF_SUPPORTED. Note that I changed meaning from negative to = positive, that is

more = appropriate for status type notification and also makes it possible to = easy extend

protocol in case a = new fictional AF appears in future.

 

In this case the = server can make an assignment of the IP addresses decoupled = from

the returned = notifications, which in this case become almost static: you can = _always_

return = corresponding IP*_AF_SUPPORTED (either one of them or both) regardless = of whether

you assigned IPs = or not and which AF you assigned. That makes server implementation = simpler.

The only case when = server need to return more is the 4th case, when it would in addition = send

SINGLE_AF_SUPPORTED= (actually it is not all that needed and the client can easily deduce = it,

but let's make his = life simpler).

 

This is mostly ad = hoc design, it can definitely be discussed.

 

Regards,=

Valery.<= /span>

 

 

Hi, =

 

One of the comment was the number of AF failure error. = I think Med already answered this comment [1], see the question/answer = below. If that does not address the question raised today, please = describe how the number could be reduced.

 

Please also state whether we should use one status = code for all AF failure error versus one status code per AF failure = error. I think the WG preferred the latest = alternative.

 

Yours

Daniel

 

"""

* Looking = at the code points, I have the impression that with the current = signaling, only the case where a single af is supported could be = ambiguous. A host sending a request for IP4 and IP6 addresses, can = easily deduce is which are the supported AF, except when the a single AF = is supported.

 

[Med] There are cases where both AFs are supported, = but only an address/prefix can be returned. Which address is returned is = policy-based. An initiator which does not get an address family type = does not know whether it didn=E2=80=99t get the requested AF because (1) = it is not supported or (2) because of a policy. The behavior of the = initiator may change as function of this. = 

For =
example, if it really needs an IPv4, but gets an IPv6 prefix, it will =
need to issue a request in which only INTERNAL_IP4_ADDRESS will be included and so on.   

""" =

------=_NextPart_000_0281_01D476F1.064220E0-- From nobody Wed Nov 7 09:56:58 2018 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 0C36A12D4EC for ; Wed, 7 Nov 2018 09:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 m-572Om4SKTO for ; Wed, 7 Nov 2018 09:56:54 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7B712D4EB for ; Wed, 7 Nov 2018 09:56:54 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 42qvHm3M0rz10Rd; Wed, 7 Nov 2018 18:56:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 42qvHm27W9zFpWX; Wed, 7 Nov 2018 18:56:52 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 18:56:52 +0100 From: To: Valery Smyslov , 'Daniel Migault' , 'IPsecME WG' Thread-Topic: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes) Thread-Index: AQHUdn94nogjrr0u2k2DDStQkAsj7KVEbuqAgAApWxA= Date: Wed, 7 Nov 2018 17:56:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E0416B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <028001d476b6$59e19b30$0da4d190$@gmail.com> In-Reply-To: <028001d476b6$59e19b30$0da4d190$@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E0416B9OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] draft-boucadair-ipsecme-ipv6-ipv4-codes (too many codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 17:56:57 -0000 --_000_787AE7BB302AE849A7480A190F8B93302E0416B9OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmFsZXJ5LA0KDQpUaGFuayB5b3UgZm9yIGVsYWJvcmF0aW5nLg0KDQpQbGVhc2Ugc2VlIGlu bGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSVBzZWMgW21haWx0bzppcHNlYy1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFZhbGVyeSBTbXlzbG92DQpFbnZvecOpIDogbWVyY3Jl ZGkgNyBub3ZlbWJyZSAyMDE4IDE3OjI0DQrDgCA6ICdEYW5pZWwgTWlnYXVsdCc7ICdJUHNlY01F IFdHJw0KT2JqZXQgOiBSZTogW0lQc2VjXSBkcmFmdC1ib3VjYWRhaXItaXBzZWNtZS1pcHY2LWlw djQtY29kZXMgKHRvbyBtYW55IGNvZGVzKQ0KDQpIaSBEYW5pZWwsDQoNCml0IHdhcyBtZSB3aG8g bWFkZSB0aGlzIGNvbW1lbnQuIFRoZSBjdXJyZW50IG51bWJlciBvZiBub3RpZmljYXRpb25zIHNl ZW1zIHRvIGJlIGV4Y2Vzc2l2ZSBmb3INCnRoZSB0YXNrLiBOb3QgdGhhdCBJJ20gYWxsIHRoYXQg Z3JlZWR5IChhbHNvIE9jY2FtIHJhem9yIGhhcyBiZWVuIHNpdHRpbmcgc2l0dGluZyBpbiBteSBt aW5kKSwNCmJ1dCB0aGUgY3VycmVudCBkZXNpZ24gbWFrZXMgaW1wbGVtZW50YXRpb24gbW9yZSBj b21wbGV4IHRoZW4gaXQgY291bGQgYmUuDQoNCllvdSBoYXZlIGEgc2VwYXJhdGUgbm90aWZpY2F0 aW9uIGZvciBlYWNoIHBvc3NpYmxlIHNpdHVhdGlvbi4gVGhhdCBtYWtlcyB0aGUgcmVzcG9uZGVy DQp0aGluayBiZWZvcmUgcmV0dXJuaW5nIGJhY2sgYSAicHJvcGVyIiBhbnN3ZXIuIEJ1dCBhY3R1 YWxseSwgbW9zdCBvZiB0aGVzZSBkaWZmZXJlbnQNCm5vdGlmaWNhdGlvbnMgcmV0dXJuIGV4YWN0 bHkgdGhlIHNhbWUgdHdvIGJpdCBvZiBpbmZvcm1hdGlvbiAtIHdoaWNoIGFkZHJlc3MgZmFtaWxp ZXMgYXJlIHN1cHBvcnRlZA0KYnkgdGhlIHNlcnZlciAob3IgYWxsb3dlZCBieSBpdHMgcG9saWN5 KS4gTW9yZW92ZXIsIHRoaXMgdHdvIGJpdHMgb2YgaW5mb3JtYXRpb24gYXJlIG1vc3RseSBzdGF0 aWMhDQoNClNvLCB3aGF0IGRlc2lnbiBJIHdvdWxkIGhhdmUgcHJlZmVycmVkPyBUd28gbm90aWZp Y2F0aW9ucyBhcmUgZW5vdWdoIC0gU1VQUE9SVEVEX0FGIChjb250YWluaW5nDQpzb21lIGRhdGEg aW5kaWNhdGluZyB3aGljaCBBRnMgYXJlIHN1cHBvcnRlZCkgYW5kIFNJTkdMRV9BRl9TVVBQT1JU RUQuIElmIHlvdSBkb24ndCBsaWtlDQpub3RpZmljYXRpb24gZGF0YSwgdGhlbiB0aHJlZSBub3Rp ZmljYXRpb25zIGFyZSBlbm91Z2ggLSBJUDRfQUZfU1VQUE9SVEVELCBJUDZfQUZfU1VQUE9SVEVE DQphbmQgU0lOR0xFX0FGX1NVUFBPUlRFRC4NCg0KW01lZF0gSeKAmWQgcHJlZmVyIHRvIGF2b2lk IG5vdGlmaWNhdGlvbiBkYXRhLCBzbyBJIHdpbGwgY29uc2lkZXIgdGhlIHRocmVlIG5vdGlmaWNh dGlvbnMgYXBwcm9hY2guDQoNCk5vdGUgdGhhdCBJIGNoYW5nZWQgbWVhbmluZyBmcm9tIG5lZ2F0 aXZlIHRvIHBvc2l0aXZlLCB0aGF0IGlzDQptb3JlIGFwcHJvcHJpYXRlIGZvciBzdGF0dXMgdHlw ZSBub3RpZmljYXRpb24gYW5kIGFsc28gbWFrZXMgaXQgcG9zc2libGUgdG8gZWFzeSBleHRlbmQN CnByb3RvY29sIGluIGNhc2UgYSBuZXcgZmljdGlvbmFsIEFGIGFwcGVhcnMgaW4gZnV0dXJlLg0K DQpJbiB0aGlzIGNhc2UgdGhlIHNlcnZlciBjYW4gbWFrZSBhbiBhc3NpZ25tZW50IG9mIHRoZSBJ UCBhZGRyZXNzZXMgZGVjb3VwbGVkIGZyb20NCnRoZSByZXR1cm5lZCBub3RpZmljYXRpb25zLCB3 aGljaCBpbiB0aGlzIGNhc2UgYmVjb21lIGFsbW9zdCBzdGF0aWM6IHlvdSBjYW4gX2Fsd2F5c18N CnJldHVybiBjb3JyZXNwb25kaW5nIElQKl9BRl9TVVBQT1JURUQgKGVpdGhlciBvbmUgb2YgdGhl bSBvciBib3RoKSByZWdhcmRsZXNzIG9mIHdoZXRoZXINCnlvdSBhc3NpZ25lZCBJUHMgb3Igbm90 IGFuZCB3aGljaCBBRiB5b3UgYXNzaWduZWQuIFRoYXQgbWFrZXMgc2VydmVyIGltcGxlbWVudGF0 aW9uIHNpbXBsZXIuDQpUaGUgb25seSBjYXNlIHdoZW4gc2VydmVyIG5lZWQgdG8gcmV0dXJuIG1v cmUgaXMgdGhlIDR0aCBjYXNlLCB3aGVuIGl0IHdvdWxkIGluIGFkZGl0aW9uIHNlbmQNClNJTkdM RV9BRl9TVVBQT1JURUQgKGFjdHVhbGx5IGl0IGlzIG5vdCBhbGwgdGhhdCBuZWVkZWQgYW5kIHRo ZSBjbGllbnQgY2FuIGVhc2lseSBkZWR1Y2UgaXQsDQpidXQgbGV0J3MgbWFrZSBoaXMgbGlmZSBz aW1wbGVyKS4NCg0KW01lZF0gSSBkbyBwcmVmZXIgdG8gbWFrZSBpdCBleHBsaWNpdCwgaGVuY2Ug dGhlIG1haW50YWluIG9mIFNJTkdMRV9BRl9TVVBQT1JURUQuDQoNCg0KVGhpcyBpcyBtb3N0bHkg YWQgaG9jIGRlc2lnbiwgaXQgY2FuIGRlZmluaXRlbHkgYmUgZGlzY3Vzc2VkLg0KDQpSZWdhcmRz LA0KVmFsZXJ5Lg0KDQoNCkhpLA0KDQpPbmUgb2YgdGhlIGNvbW1lbnQgd2FzIHRoZSBudW1iZXIg b2YgQUYgZmFpbHVyZSBlcnJvci4gSSB0aGluayBNZWQgYWxyZWFkeSBhbnN3ZXJlZCB0aGlzIGNv bW1lbnQgWzFdLCBzZWUgdGhlIHF1ZXN0aW9uL2Fuc3dlciBiZWxvdy4gSWYgdGhhdCBkb2VzIG5v dCBhZGRyZXNzIHRoZSBxdWVzdGlvbiByYWlzZWQgdG9kYXksIHBsZWFzZSBkZXNjcmliZSBob3cg dGhlIG51bWJlciBjb3VsZCBiZSByZWR1Y2VkLg0KDQpQbGVhc2UgYWxzbyBzdGF0ZSB3aGV0aGVy IHdlIHNob3VsZCB1c2Ugb25lIHN0YXR1cyBjb2RlIGZvciBhbGwgQUYgZmFpbHVyZSBlcnJvciB2 ZXJzdXMgb25lIHN0YXR1cyBjb2RlIHBlciBBRiBmYWlsdXJlIGVycm9yLiBJIHRoaW5rIHRoZSBX RyBwcmVmZXJyZWQgdGhlIGxhdGVzdCBhbHRlcm5hdGl2ZS4NCg0KWW91cnMNCkRhbmllbA0KDQpb MV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pcHNlYy8zRE1fTXpMbUct SllLR2JBMTVzaUNrSmJxVjgNCiIiIg0KKiBMb29raW5nIGF0IHRoZSBjb2RlIHBvaW50cywgSSBo YXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgd2l0aCB0aGUgY3VycmVudCBzaWduYWxpbmcsIG9ubHkg dGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgYWYgaXMgc3VwcG9ydGVkIGNvdWxkIGJlIGFtYmlndW91 cy4gQSBob3N0IHNlbmRpbmcgYSByZXF1ZXN0IGZvciBJUDQgYW5kIElQNiBhZGRyZXNzZXMsIGNh biBlYXNpbHkgZGVkdWNlIGlzIHdoaWNoIGFyZSB0aGUgc3VwcG9ydGVkIEFGLCBleGNlcHQgd2hl biB0aGUgYSBzaW5nbGUgQUYgaXMgc3VwcG9ydGVkLg0KDQpbTWVkXSBUaGVyZSBhcmUgY2FzZXMg d2hlcmUgYm90aCBBRnMgYXJlIHN1cHBvcnRlZCwgYnV0IG9ubHkgYW4gYWRkcmVzcy9wcmVmaXgg Y2FuIGJlIHJldHVybmVkLiBXaGljaCBhZGRyZXNzIGlzIHJldHVybmVkIGlzIHBvbGljeS1iYXNl ZC4gQW4gaW5pdGlhdG9yIHdoaWNoIGRvZXMgbm90IGdldCBhbiBhZGRyZXNzIGZhbWlseSB0eXBl IGRvZXMgbm90IGtub3cgd2hldGhlciBpdCBkaWRu4oCZdCBnZXQgdGhlIHJlcXVlc3RlZCBBRiBi ZWNhdXNlICgxKSBpdCBpcyBub3Qgc3VwcG9ydGVkIG9yICgyKSBiZWNhdXNlIG9mIGEgcG9saWN5 LiBUaGUgYmVoYXZpb3Igb2YgdGhlIGluaXRpYXRvciBtYXkgY2hhbmdlIGFzIGZ1bmN0aW9uIG9m IHRoaXMuDQoNCkZvciBleGFtcGxlLCBpZiBpdCByZWFsbHkgbmVlZHMgYW4gSVB2NCwgYnV0IGdl dHMgYW4gSVB2NiBwcmVmaXgsIGl0IHdpbGwgbmVlZCB0byBpc3N1ZSBhIHJlcXVlc3QgaW4gd2hp Y2ggb25seSBJTlRFUk5BTF9JUDRfQUREUkVTUyB3aWxsIGJlIGluY2x1ZGVkIGFuZCBzbyBvbi4N CiIiIg0K --_000_787AE7BB302AE849A7480A190F8B93302E0416B9OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0K CXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVk LCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6UlU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46Mi4w Y20gNDIuNXB0IDIuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgVmFsZXJ5LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9yIGVs YWJvcmF0aW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFZhbGVyeSBTbXlzbG92 PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDcgbm92ZW1icmUgMjAxOCAxNzoy NDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gJ0RhbmllbCBNaWdhdWx0JzsgJ0lQc2VjTUUgV0cnPGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0lQc2VjXSBkcmFmdC1ib3VjYWRhaXItaXBzZWNt ZS1pcHY2LWlwdjQtY29kZXMgKHRvbyBtYW55IGNvZGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgRGFuaWVsLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5pdCB3YXMgbWUgd2hvIG1hZGUgdGhpcyBjb21tZW50LiBUaGUgY3VycmVudCBudW1iZXIgb2Yg bm90aWZpY2F0aW9ucyBzZWVtcyB0byBiZSBleGNlc3NpdmUgZm9yPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50aGUgdGFzay4gTm90IHRo YXQgSSdtIGFsbCB0aGF0IGdyZWVkeSAoYWxzbyBPY2NhbSByYXpvciBoYXMgYmVlbiBzaXR0aW5n IHNpdHRpbmcgaW4gbXkgbWluZCksDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmJ1dCB0aGUgY3VycmVudCBkZXNpZ24gbWFrZXMgaW1w bGVtZW50YXRpb24gbW9yZSBjb21wbGV4IHRoZW4gaXQgY291bGQgYmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPllvdSBo YXZlIGEgc2VwYXJhdGUgbm90aWZpY2F0aW9uIGZvciBlYWNoIHBvc3NpYmxlIHNpdHVhdGlvbi4g VGhhdCBtYWtlcyB0aGUgcmVzcG9uZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50aGluayBiZWZvcmUgcmV0dXJuaW5nIGJhY2sgYSAm cXVvdDtwcm9wZXImcXVvdDsgYW5zd2VyLiBCdXQgYWN0dWFsbHksIG1vc3Qgb2YgdGhlc2UgZGlm ZmVyZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5ub3RpZmljYXRpb25zIHJldHVybiBleGFjdGx5IHRoZSBzYW1lIHR3byBiaXQgb2Yg aW5mb3JtYXRpb24gLSB3aGljaCBhZGRyZXNzIGZhbWlsaWVzIGFyZSBzdXBwb3J0ZWQNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Ynkg dGhlIHNlcnZlciAob3IgYWxsb3dlZCBieSBpdHMgcG9saWN5KS4gTW9yZW92ZXIsIHRoaXMgdHdv IGJpdHMgb2YgaW5mb3JtYXRpb24gYXJlIG1vc3RseSBzdGF0aWMhDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIHdo YXQgZGVzaWduIEkgd291bGQgaGF2ZSBwcmVmZXJyZWQ/IFR3byBub3RpZmljYXRpb25zIGFyZSBl bm91Z2ggLSBTVVBQT1JURURfQUYgKGNvbnRhaW5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnNvbWUgZGF0YSBpbmRpY2F0aW5nIHdo aWNoIEFGcyBhcmUgc3VwcG9ydGVkKSBhbmQgU0lOR0xFX0FGX1NVUFBPUlRFRC4gSWYgeW91IGRv bid0IGxpa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPm5vdGlmaWNhdGlvbiBkYXRhLCB0aGVuIHRocmVlIG5vdGlmaWNhdGlvbnMgYXJl IGVub3VnaCAtIElQNF9BRl9TVVBQT1JURUQsIElQNl9BRl9TVVBQT1JURUQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmFuZCBTSU5HTEVf QUZfU1VQUE9SVEVELjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5bTWVkXSBJ4oCZZCBwcmVmZXIg dG8gYXZvaWQgbm90aWZpY2F0aW9uIGRhdGEsIHNvIEkgd2lsbCBjb25zaWRlciB0aGUgdGhyZWUg bm90aWZpY2F0aW9ucyBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90ZSB0aGF0IEkgY2hhbmdlZCBtZWFuaW5nIGZyb20g bmVnYXRpdmUgdG8gcG9zaXRpdmUsIHRoYXQgaXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+bW9yZSBhcHByb3ByaWF0ZSBmb3Igc3Rh dHVzIHR5cGUgbm90aWZpY2F0aW9uIGFuZCBhbHNvIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGVhc3kg ZXh0ZW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPnByb3RvY29sIGluIGNhc2UgYSBuZXcgZmljdGlvbmFsIEFGIGFwcGVhcnMgaW4g ZnV0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JbiB0aGlzIGNhc2UgdGhlIHNlcnZlciBjYW4gbWFrZSBhbiBhc3Np Z25tZW50IG9mIHRoZSBJUCBhZGRyZXNzZXMgZGVjb3VwbGVkIGZyb208bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnRoZSByZXR1cm5lZCBu b3RpZmljYXRpb25zLCB3aGljaCBpbiB0aGlzIGNhc2UgYmVjb21lIGFsbW9zdCBzdGF0aWM6IHlv dSBjYW4gX2Fsd2F5c188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPnJldHVybiBjb3JyZXNwb25kaW5nIElQKl9BRl9TVVBQT1JURUQgKGVp dGhlciBvbmUgb2YgdGhlbSBvciBib3RoKSByZWdhcmRsZXNzIG9mIHdoZXRoZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnlvdSBhc3Np Z25lZCBJUHMgb3Igbm90IGFuZCB3aGljaCBBRiB5b3UgYXNzaWduZWQuIFRoYXQgbWFrZXMgc2Vy dmVyIGltcGxlbWVudGF0aW9uIHNpbXBsZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBvbmx5IGNhc2Ugd2hlbiBzZXJ2ZXIg bmVlZCB0byByZXR1cm4gbW9yZSBpcyB0aGUgNHRoIGNhc2UsIHdoZW4gaXQgd291bGQgaW4gYWRk aXRpb24gc2VuZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5TSU5HTEVfQUZfU1VQUE9SVEVEIChhY3R1YWxseSBpdCBpcyBub3QgYWxs IHRoYXQgbmVlZGVkIGFuZCB0aGUgY2xpZW50IGNhbiBlYXNpbHkgZGVkdWNlIGl0LA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5idXQg bGV0J3MgbWFrZSBoaXMgbGlmZSBzaW1wbGVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+W01lZF0gSSBkbyBwcmVmZXIgdG8gbWFrZSBpdCBleHBsaWNp dCwgaGVuY2UgdGhlIG1haW50YWluIG9mIFNJTkdMRV9BRl9TVVBQT1JURUQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhp cyBpcyBtb3N0bHkgYWQgaG9jIGRlc2lnbiwgaXQgY2FuIGRlZmluaXRlbHkgYmUgZGlzY3Vzc2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VmFsZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPk9uZSBvZiB0aGUgY29tbWVudCB3YXMg dGhlIG51bWJlciBvZiBBRiBmYWlsdXJlIGVycm9yLiBJIHRoaW5rIE1lZCBhbHJlYWR5IGFuc3dl cmVkIHRoaXMgY29tbWVudCBbMV0sIHNlZSB0aGUgcXVlc3Rpb24vYW5zd2VyIGJlbG93LiBJZiB0 aGF0IGRvZXMgbm90IGFkZHJlc3MgdGhlIHF1ZXN0aW9uIHJhaXNlZCB0b2RheSwgcGxlYXNlIGRl c2NyaWJlIGhvdyB0aGUgbnVtYmVyIGNvdWxkDQogYmUgcmVkdWNlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPlBsZWFzZSBhbHNvIHN0YXRlIHdoZXRoZXIgd2Ug c2hvdWxkIHVzZSBvbmUgc3RhdHVzIGNvZGUgZm9yIGFsbCBBRiBmYWlsdXJlIGVycm9yIHZlcnN1 cyBvbmUgc3RhdHVzIGNvZGUgcGVyIEFGIGZhaWx1cmUgZXJyb3IuIEkgdGhpbmsgdGhlIFdHIHBy ZWZlcnJlZCB0aGUgbGF0ZXN0IGFsdGVybmF0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+WW91cnMgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPkRhbmllbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+WzFdIDxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaXBzZWMvM0RNX016TG1HLUpZS0diQTE1c2lD a0picVY4Ij4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaXBzZWMvM0RN X016TG1HLUpZS0diQTE1c2lDa0picVY4PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mcXVvdDsmcXVv dDsmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJSVSI+KiBMb29raW5nIGF0IHRoZSBjb2Rl IHBvaW50cywgSSBoYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgd2l0aCB0aGUgY3VycmVudCBzaWdu YWxpbmcsIG9ubHkgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgYWYgaXMgc3VwcG9ydGVkIGNvdWxk IGJlIGFtYmlndW91cy4gQSBob3N0IHNlbmRpbmcNCiBhIHJlcXVlc3QgZm9yIElQNCBhbmQgSVA2 IGFkZHJlc3NlcywgY2FuIGVhc2lseSBkZWR1Y2UgaXMgd2hpY2ggYXJlIHRoZSBzdXBwb3J0ZWQg QUYsIGV4Y2VwdCB3aGVuIHRoZSBhIHNpbmdsZSBBRiBpcyBzdXBwb3J0ZWQuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+W01lZF0gVGhlcmUgYXJlIGNhc2VzIHdoZXJlIGJvdGggQUZzIGFyZSBzdXBw b3J0ZWQsIGJ1dCBvbmx5IGFuIGFkZHJlc3MvcHJlZml4IGNhbiBiZSByZXR1cm5lZC4NCiBXaGlj aCBhZGRyZXNzIGlzIHJldHVybmVkIGlzIHBvbGljeS1iYXNlZC4gQW4gaW5pdGlhdG9yIHdoaWNo IGRvZXMgbm90IGdldCBhbiBhZGRyZXNzIGZhbWlseSB0eXBlIGRvZXMgbm90IGtub3cgd2hldGhl ciBpdCBkaWRu4oCZdCBnZXQgdGhlIHJlcXVlc3RlZCBBRiBiZWNhdXNlICgxKSBpdCBpcyBub3Qg c3VwcG9ydGVkIG9yICgyKSBiZWNhdXNlIG9mIGEgcG9saWN5LiBUaGUgYmVoYXZpb3Igb2YgdGhl IGluaXRpYXRvciBtYXkgY2hhbmdlIGFzIGZ1bmN0aW9uDQogb2YgdGhpcy4gPC9zcGFuPjxzcGFu IGxhbmc9IlJVIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPkZvciBleGFtcGxlLCBpZiBpdCByZWFsbHkgbmVlZHMgYW4g SVB2NCwgYnV0IGdldHMgYW4gSVB2NiBwcmVmaXgsIGl0IHdpbGwgbmVlZCB0byBpc3N1ZSBhIHJl cXVlc3QgaW4gd2hpY2ggb25seSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklOVEVSTkFMX0lQ NF9BRERSRVNTIHdpbGwgYmUgaW5jbHVkZWQgYW5kIHNvIG9uLiA8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iUlUiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZxdW90OyZxdW90OyZxdW90Ow0KPC9zcGFuPjxzcGFuIGxhbmc9 IlJVIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302E0416B9OPEXCLILMA3corp_-- From nobody Wed Nov 7 21:07:19 2018 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 1C902130DC8 for ; Wed, 7 Nov 2018 21:07:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 szyHD4Mkt8qC for ; Wed, 7 Nov 2018 21:07:16 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 A1407126CB6 for ; Wed, 7 Nov 2018 21:07:16 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id c13-v6so8950155plz.13 for ; Wed, 07 Nov 2018 21:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=G4UP3v3KdKfZf18/0+hd21E79NOOoSDSqYt/GIiTqZA=; b=nj+tVrq4zmlXBT2hYdHRxZxz6VzhMFtkFJe9gd7Jt1DnNq1+7CYpxAN16KD8Xt89HF uwRh33qSbc1xuFsnYuMaNr9tVSa6vrgv0jRMjbUqefi8cpDqLCgiwo71o1Cg/YA2oww+ izvHlV4jt1ZEKj7fAQKsfirrFFZj+WQw2yYmvCS0IUO7O134OgMsKnIeEIogpQb+PLUA sWldUUSjt8WCeHIb6DLoR/T2fCuM260J8hlhSeCW/0IHAvN/HWDsq2iX5K63JRqRXZQ2 XGdbxg125Qt1iS2cO/CNU80Bfsc5BZGwgtk4TW2xVx4bjMkyCmQHZMZUlK4GJ1YmYIy0 7jYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=G4UP3v3KdKfZf18/0+hd21E79NOOoSDSqYt/GIiTqZA=; b=nTqgW/6BUQIl2scNpmuJSEzcx3o2x/xEOjXk1ZWGaOlUS10QCrcgrERzH7FrwLfYTN MNDVQXi5aojE50nUC6fzmCYeTnvt0GmRH8Gycl3JVu1P/JGtL91lhANRsXzvY0oM/HhV +rE5d9xzYpnpfuIQf/fnc4oWpO2wfx4cKnxLQyc6fWUXJWPw67Hzd7bXNCuWG0sQbm2u tWl9R2X7835L6sMeIVZA4Gy6MK6PIR78/FtYpYQDJrXfnfOZPAHS7auCd1B8N3YojTwr yX2LQlvP6DG4TX8SpuMAcjhPck5AjB7sIVOVscG1NHzdUGdDQqkBXoYlOCGDzfp6qflz zY6g== X-Gm-Message-State: AGRZ1gKkKlw8CqUz8S4obkst/CWKUD3CPLjmCnZOuEQ9pUNGmlPLZaMh BBmpieoCwa7b9C5PgTzHiUNXEwKRpwM= X-Google-Smtp-Source: AJdET5dBY2W3zes9pM7qGDgLpKiGHYtFL7b3OGhW2xPD+Nd2b8iQtoNVgFX3lD2drJaqSrpfpifghA== X-Received: by 2002:a17:902:aa46:: with SMTP id c6-v6mr3224227plr.182.1541653635532; Wed, 07 Nov 2018 21:07:15 -0800 (PST) Received: from svannotebook ([2001:67c:370:128:d0fc:a79b:6612:e3cb]) by smtp.gmail.com with ESMTPSA id d197-v6sm3828845pga.1.2018.11.07.21.07.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 21:07:15 -0800 (PST) From: "Valery Smyslov" To: "'IPsecME WG'" Date: Thu, 8 Nov 2018 12:07:12 +0700 Message-ID: <031f01d47720$e9fb8220$bdf28660$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdR3Hk31rop2W0hhSPSOG6Xzw31sYw== Content-Language: ru Archived-At: Subject: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 05:07:18 -0000 Hi, coming back to the yesterday discussion. There seems to be another issue if implementation first sends request to update address over UDP and then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - it contains IP addresses and ports for initiator and responder. If you leave it intact while switching to TCP, then it won't match real addresses and the responder will treat it as NAT presence. In this case RFC 4555 suggests to retry sending request several times with a new INFORMATIONAL request. Probably we could clarify in TCP guidelines draft that the content of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? Regards, Valery. From nobody Wed Nov 7 21:16:44 2018 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 8318B130DCF for ; Wed, 7 Nov 2018 21:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6j7ILbvOWW67 for ; Wed, 7 Nov 2018 21:16:40 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 40C7E126CB6 for ; Wed, 7 Nov 2018 21:16:40 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id s5-v6so8955242plq.11 for ; Wed, 07 Nov 2018 21:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MBnRRpK+Q5JP6asUHNQ05eSotZKqp0zve/fHl4GtluY=; b=uvmF8gHD/44kni2eAVHwohtAMrFlFhgDtQdR8a85zBcdEK/T1O4qqtV9tYNweNiCFY ACUawNU/wEFRQsI/3Hu3EylFq4Kqm6z1RXPvHc65iRT6tRBr2yLKKg0cGq721gvYccv2 4z1LxDro+isuuTFBDlTcUxp/yoBO+LwUVD8AhaRvUDHC4IzreYU/5gSdn/SAG3DP313V uiXtJ1P3AgVDDGTdIH/JxDB5inHiA3K/y5Yd/OImum0MiqRdGWVAvA1ohC/W4PJbCbbc iKWI2wabQDBKFbNRLNZl/4t5b1GGi5ICSMpdnR+2n3saJPOJ6SjjzDOKg4Q4zXkoq1YS qfdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MBnRRpK+Q5JP6asUHNQ05eSotZKqp0zve/fHl4GtluY=; b=hRQ6UZW9eUck7oK5CxBTyhDu/gA1jPxPhNkmZT5sz0pbrPD6Lg9+X3KZfjYWSPYi7s SFQp1UybuJqNWhpbhoDu2nsom/NdsVnWfRnPEYTIyeU3xuV1A1NPNSUv0fZEwW4fYDPM kvV3r0T5ZlQOb0CQSZP7QmlGEoNzPnU1+xIazi7RX0pZ0AeO+Hf0YuweK3ZIEalZmVSJ 4NziwJ1PxQwADZLrwTPkSSQ7wyvsHutATPXFyLBwVvZlveX10UGLuidrJXiGk/99scpD 7F8Cb4j1nXQVUt7ANzP+yqSSAQrg12nBpqVqC8rXCJDsLduNrBwGp/71OlhmzgJV/y76 PcYA== X-Gm-Message-State: AGRZ1gKl1gjUoLOl2pic4Qu2C7qAeaiwuhmUajS/9usXNhDcvNACc4p4 7TO6MA2RXu0FsjJNmzwEaH/uQ9KPg2nCvSl4fyM= X-Google-Smtp-Source: AJdET5fIoN3K0QZQJfKaX8kGZUmXnjec9tT1D2Rp1QHH5SHZmI7GmIRBU8quge+hVaOCEVFKvfAQNkEvFbENSCGwXdE= X-Received: by 2002:a17:902:b18c:: with SMTP id s12-v6mr3116935plr.16.1541654199824; Wed, 07 Nov 2018 21:16:39 -0800 (PST) MIME-Version: 1.0 References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> In-Reply-To: <031f01d47720$e9fb8220$bdf28660$@gmail.com> From: David Schinazi Date: Thu, 8 Nov 2018 12:16:28 +0700 Message-ID: To: smyslov.ietf@gmail.com Cc: ipsec@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2769c057a205645" Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 05:16:43 -0000 --000000000000f2769c057a205645 Content-Type: text/plain; charset="UTF-8" I'm having a hard time imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it means that there is something on path even worse than a NAT, right? Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encaps? David On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov wrote: > Hi, > > coming back to the yesterday discussion. There seems to be another issue > if implementation first sends request to update address over UDP and > then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - > it contains IP addresses and ports for initiator and responder. If you > leave it intact while switching to TCP, then it won't match real addresses > and the responder will treat it as NAT presence. In this case RFC 4555 > suggests to retry sending request several times with a new INFORMATIONAL > request. Probably we could clarify in TCP guidelines draft that the content > of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000f2769c057a205645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm having a hard ti= me imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsul= ation. If you're encapsulating in TCP it means that there is something = on path even worse than a NAT, right?

= Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encap= s?

David

On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov <= smyslov.ietf@gmail.com> wr= ote:
Hi,

coming back to the yesterday discussion. There seems to be another issue if implementation first sends request to update address over UDP and
then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - <= br> it contains IP addresses and ports for initiator and responder. If you
leave it intact while switching to TCP, then it won't match real addres= ses
and the responder will treat it as NAT presence. In this case RFC 4555
suggests to retry sending request several times with a new INFORMATIONAL request. Probably we could clarify in TCP guidelines draft that the content=
of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious?

Regards,
Valery.


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000f2769c057a205645-- From nobody Wed Nov 7 21:36:35 2018 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 D29A313107E for ; Wed, 7 Nov 2018 21:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EF_qHGJ3ISkg for ; Wed, 7 Nov 2018 21:36:27 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 35AFA130EBB for ; Wed, 7 Nov 2018 21:36:20 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id d13-v6so1626952pfo.3 for ; Wed, 07 Nov 2018 21:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=oW3hfy8nfJfxxFbJDj9G4RwW2UH9+XTw29dS23Pktug=; b=H3cnLfE+FI282xhHsxR1RjVS6IwpXL/g3J3Zz4gfx8oor/oaahU4FTw8IcsMjmYy8M tqlVVLnuWnbzHYFXBEzOkl57uDQk/JgNtiYqQzQsLdGidS1dozbQRCJ45NoK7nGEv+gO QEicx/YmQJGnF24CgE3AU6J1SLLbJSnp+Vur9pNxk2Cgo80qq+BrjbKGtkVC4CIgKrU1 OyJRpcu86WAagmLLp7rMMZSZfR23+eHhBgSZDOBZB969hVLSxdhVwi+cIAqecakUhkVB cwZVDEvP/ewr+a2RDSEKF2L8gFYrpfnNfx1tzlQ0fFG1EQF2x4iwbKdfMVe4lVG7o2Wj bETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=oW3hfy8nfJfxxFbJDj9G4RwW2UH9+XTw29dS23Pktug=; b=LwBlPxnGiN/LL3ptNjtDUyQ8ntSyFWSP3/hjssIRg1T0TVLbKQ2gvkDsrpGBE3YZLE j0FabQWhvwd/+OaJzTN8HQb4tIIJQhuc6q9MdWZw1kv8xgfluhv/8DHOaHAZde2XantO L4MJKE8m2Gj0cXT0lxfKgf9dNOHASPB5PbGO7/kNNSxDklpW8syDKOyM5e88IKQOeMsh Y38j2MelPlTMZNuap1Dv0ZHvjqJaAtG7EMnmUBW5hzQBjazG7npf+Q5U5s/ZgJfFPwpM pwvaEKRMkc0JcCgqHjUXm/tnLLQ2gCH0JX2bRY07UXuZ2io3uSjn8UMJNKccfASD7O6U sSkg== X-Gm-Message-State: AGRZ1gKpa0zj8A3ua3i4Zc7Kgc6WHngcN6oIeHqeonI8htAQaZ73MLyK rP6BhviVf5Xc2RvloXqlFmM= X-Google-Smtp-Source: AJdET5cgUCv5z+v+H5VGzH1XzCojQAUt2r2BDAg4fGXks81LxktbKxMLpuDGPNg8tAQQhItp8u6hLQ== X-Received: by 2002:a63:1204:: with SMTP id h4mr2729472pgl.51.1541655379354; Wed, 07 Nov 2018 21:36:19 -0800 (PST) Received: from svannotebook ([2001:67c:1232:144:e423:48:6da9:175f]) by smtp.gmail.com with ESMTPSA id s141-v6sm5273967pfc.63.2018.11.07.21.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 21:36:18 -0800 (PST) From: "Valery Smyslov" To: "'David Schinazi'" Cc: References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> In-Reply-To: Date: Thu, 8 Nov 2018 12:36:14 +0700 Message-ID: <032c01d47724$f906d6d0$eb148470$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032D_01D4775F.A56D01D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQINC5x2IttgBeVJM8GBpgLrp7BrywFkiMAmpMkKaGA= Content-Language: ru Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 05:36:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032D_01D4775F.A56D01D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP? I think that in general the co-existence of MOBIKE and TCP must be elaborated in more detail in the draft. =20 =20 =20 I'm having a hard time imagining why anyone would want to use = NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP = it means that there is something on path even worse than a NAT, right? =20 Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP = encaps? =20 David =20 On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov > wrote: Hi, coming back to the yesterday discussion. There seems to be another issue = if implementation first sends request to update address over UDP and then switches to TCP. The problem arises if NO_NATS_ALLOWED is included = -=20 it contains IP addresses and ports for initiator and responder. If you leave it intact while switching to TCP, then it won't match real = addresses and the responder will treat it as NAT presence. In this case RFC 4555 suggests to retry sending request several times with a new INFORMATIONAL request. Probably we could clarify in TCP guidelines draft that the = content of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org =20 https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_032D_01D4775F.A56D01D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hmm, = maybe. Or maybe not. Or maybe just ignore it in case of = TCP?

I think that in = general the co-existence of MOBIKE and TCP must = be

elaborated in more = detail in the draft.

 

 

 

I'm having a hard time imagining = why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. = If you're encapsulating in TCP it means that there is something = on path even worse than a NAT, right?

 

Perhaps we could simply say you MUST NOT use = NO_NATS_ALLOWED with TCP encaps?

 

David

 

On = Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov <smyslov.ietf@gmail.com> = wrote:

Hi,

coming back to the yesterday discussion. = There seems to be another issue
if implementation first sends = request to update address over UDP and
then switches to TCP. The = problem arises if NO_NATS_ALLOWED is included -
it contains IP = addresses and ports for initiator and responder. If you
leave it = intact while switching to TCP, then it won't match real addresses
and = the responder will treat it as NAT presence. In this case RFC = 4555
suggests to retry sending request several times with a new = INFORMATIONAL
request. Probably we could clarify in TCP guidelines = draft that the content
of NO_NATS_ALLOWED MUST be recalculated in = this case? Or is it = obvious?

Regards,
Valery.


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

------=_NextPart_000_032D_01D4775F.A56D01D0-- From nobody Thu Nov 8 05:07:43 2018 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 CFEAD129619; Thu, 8 Nov 2018 05:07:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154168245580.31150.9462703520955536832@ietfa.amsl.com> Date: Thu, 08 Nov 2018 05:07:35 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 13:07:36 -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 WG of the IETF. Title : IKEv2 Notification Status Types for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Pages : 6 Date : 2018-11-08 Abstract: This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ipv6-ipv4-codes-02 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 Thu Nov 8 05:17:00 2018 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 45264129C6B for ; Thu, 8 Nov 2018 05:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 oMMpvuLbP9Mn for ; Thu, 8 Nov 2018 05:16:56 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA7E129619 for ; Thu, 8 Nov 2018 05:16:56 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 42rP2G4MCtz4x6Y for ; Thu, 8 Nov 2018 14:16:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 42rP2G3Xhxz1xp9 for ; Thu, 8 Nov 2018 14:16:54 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0415.000; Thu, 8 Nov 2018 14:16:54 +0100 From: To: IPsecME WG Thread-Topic: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Thread-Index: AQHUd2QRm4UQYeYM3EWcvMle++2L1qVF2Z7A Date: Thu, 8 Nov 2018 13:16:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> In-Reply-To: <154168245580.31150.9462703520955536832@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 13:16:58 -0000 Dear WG,=20 First of all, I'd like to thank all those of you who commented during the i= psecme meeting on this draft. This is exactly the feedback I was looking fo= r.=20 The message I got from the WG after watching the recording is to reduce the= number of requested codes which I did in -02. This is almost close to what= is suggested by Valery and Tero. I hope that this issue is now closed.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 8 novembre 2018 14:08 > =C0=A0: i-d-announce@ietf.org > Cc=A0: ipsec@ietf.org > Objet=A0: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt >=20 >=20 > 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 W= G of > the IETF. >=20 > Title : IKEv2 Notification Status Types for IPv4/IPv6 > Coexistence > Author : Mohamed Boucadair > Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt > Pages : 6 > Date : 2018-11-08 >=20 > Abstract: > This document specifies new IKEv2 notification status types to better > manage IPv4 and IPv6 co-existence. >=20 > This document updates RFC7296. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-= 02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ipv6-ipv4-codes-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Nov 12 06:07:27 2018 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 52063130DDD for ; Mon, 12 Nov 2018 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 KyYoVcMeFjKi for ; Mon, 12 Nov 2018 06:07:24 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 1EAAA127333 for ; Mon, 12 Nov 2018 06:07:24 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id k19-v6so7698804lji.11 for ; Mon, 12 Nov 2018 06:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uEV3MDohD1VkYS1tHNclB30C9XBWiIf36S8PKtjZuyk=; b=HjvZecwic0d12MJJe+rtp1tsk9CInx99/wbqSBOOPAE35/w2WdW2osnY8dLVuJbalA dk4UW2pwn9zyJaJaROm7jl1QC2J9CeGqPkLpMf82iraKMPs6OfBUtl1o/6sNPlmmbvro Gyv1+CKh+4UaxwkrhirzDEgMqWkNAU+czBnPAqGat0Sem+3YbJc8Bp/LpL5AA1zPNt1B PZkW7qaX8bW5opkunl6yVMV90ozIBPX0bWn5FxnrtcQ1wBT8uX6Btj733ol03TEsw/lK 5bA+9uqsfEt9PmrtuQ9/jHnD7e5WsnRcMdmafnHtP81A5aee+Mdp+DJEN/Th09xadzzC qQog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uEV3MDohD1VkYS1tHNclB30C9XBWiIf36S8PKtjZuyk=; b=ot9x+Ts66zQ/vkZOXmtXiDMQgR5Qx8d2D2BGpA4GCS0j4xoYnR0eBWKEI4poLRtnPf mB9+PsYVaKawKzz00m2AKRjETWUNNCGp5f/DtM1F75LzFTu1yqML4Mq00BUVYd0n3fpd /Cxoglt6gIxLnohKEI9jmOY9vXLIyDfSUWtuyG1T6wEhj2WHuGWlAekmsCX5AR5U211g c5ebnAR7bTm9uF3NkIH0dcJdEUQ/BC7FWqdvwXetjHXUwQ8+5zYy5VrpLm12tsimyRyy y3G/zUBPfLeZK0EeVOe/9HPORJ3+0e3NTPwImrHgCChmP6uW84cKBkg8C6L/OSRNG01p B/Zg== X-Gm-Message-State: AGRZ1gJpTuMjQ6au83tn3waYUFjZB+XSSQ2W1jdB0qRc2hdqNTW+LiQH 3SK+DY8kRFOSGTgS2LU5rApH97yx X-Google-Smtp-Source: AJdET5d5/n+5CAWjVzXfMbcSih8/SQNxgIi9El7Kebc0JpydBRa9EkqBKppf5P9tWF/C7tEYQbrM/g== X-Received: by 2002:a2e:8845:: with SMTP id z5-v6mr755115ljj.98.1542031641543; Mon, 12 Nov 2018 06:07:21 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g73-v6sm3190679lje.24.2018.11.12.06.07.20 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Nov 2018 06:07:20 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Date: Mon, 12 Nov 2018 17:07:19 +0300 Message-ID: <003b01d47a91$06b04950$1410dbf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdR6j3QZwbc3SdeVRpWIgGnxF7frtw== Content-Language: ru Archived-At: Subject: [IPsec] Rename IKE_AUX? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 14:07:25 -0000 Hi, I'm going to update IKE_AUX draft (in particular - change the way it is authenticated based on recent discussion with Scott). I recall that there were some complaints that the name IKE_AUX is not good because it can easily be mixed up with IKE_AUTH Actually, the phonetically close name was selected intentionally to show that these exchanges are related. However, I'm not a native speaker and not always can realize how good or bad this similarity sounds for a native ear. So, my question to WG - do we need to change the name? If yes, then to what? Possible variants - IKE_INT (intermediate), IKE_PRE_AUTH. Something else? Regards, Valery. From nobody Mon Nov 12 13:14:33 2018 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 B831D130E7F for ; Mon, 12 Nov 2018 13:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 YkJ9MwDXl01u for ; Mon, 12 Nov 2018 13:14:31 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 20494130E02 for ; Mon, 12 Nov 2018 13:14:31 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wACLCKVM010088; Mon, 12 Nov 2018 13:14:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=7k5Wo4bSRHRZFVwRNgD2KKBsX8W0HTLDW84cPBBihh0=; b=hZUSOGO+RUvJ8+GdZewHlwBDnrjb7+5iyB5jY0RmAaXekoPuUbcDNVXhdElAQEXG46L1 azUcesxWnOl+ZNUzYIoYQhWSf1Qq+1LsWhBpRahk5EhxR45mbxAVnB6o8T+BBsJ8IOS5 ulR4v7T4JBvp6cZDiTAFsj9udpjNJFSA/mFNHUKM6I2qfJqB073PBU+AgKP+2kyPGNMK Xx7x2GnPhqnKwMFz/sF7uI/R9p8qwzYhWTI7cuCdVYLCZwifd3iLM8CCGpu2M/87dt3b cWbldhNkAnCgqIBbUd5pcdcrGksqLhjCXSQ+aDqO+ICpw68ZjePhL9a0Gyngj5CihxVN hw== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2nny582ycd-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Nov 2018 13:14:30 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PI300EZGN04C1I0@ma1-mtap-s03.corp.apple.com>; Mon, 12 Nov 2018 13:14:29 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI300100MT8NK00@nwk-mmpp-sz13.apple.com>; Mon, 12 Nov 2018 13:14:28 -0800 (PST) X-Va-A: X-Va-T-CD: 4337a09a9b1b6735ef2a05a8efd2b8b5 X-Va-E-CD: 9d2fa0de43250124a77156b859192906 X-Va-R-CD: bf1ec14a99eb035e4dae0f5edc19c4e8 X-Va-CD: 0 X-Va-ID: 0729dadb-003f-4468-862b-bcd2870d3981 X-V-A: X-V-T-CD: c32dbaa97f6cb839155684977103028d X-V-E-CD: 9d2fa0de43250124a77156b859192906 X-V-R-CD: bf1ec14a99eb035e4dae0f5edc19c4e8 X-V-CD: 0 X-V-ID: d2285238-98f3-4071-8b40-c36f73a14b1d Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI300200MUU5W00@nwk-mmpp-sz13.apple.com>; Mon, 12 Nov 2018 13:14:28 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-12_14:,, signatures=0 Received: from [17.234.38.219] (unknown [17.234.38.219]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PI300CTCN03N890@nwk-mmpp-sz13.apple.com>; Mon, 12 Nov 2018 13:14:28 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <003b01d47a91$06b04950$1410dbf0$@gmail.com> Date: Mon, 12 Nov 2018 13:14:23 -0800 Cc: IPsecME WG Message-id: References: <003b01d47a91$06b04950$1410dbf0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-12_14:, , signatures=0 Archived-At: Subject: Re: [IPsec] Rename IKE_AUX? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 21:14:33 -0000 I agree that IKE_AUX can be easily confused with IKE_AUTH. Similarly, IKE_INT looks a lot like the INIT from IKE_SA_INIT. I don't necessarily love IKE_PRE_AUTH, but it still seems preferable to the other options. You could also spell out "intermediate" to have IKE_INTERMEDIATE. This is still shorter than other existing exchange types, like IKE_SESSION_RESUME. Thanks, Tommy > On Nov 12, 2018, at 6:07 AM, Valery Smyslov wrote: > > Hi, > > I'm going to update IKE_AUX draft (in particular - change the way > it is authenticated based on recent discussion with Scott). > > I recall that there were some complaints that the name IKE_AUX > is not good because it can easily be mixed up with IKE_AUTH > Actually, the phonetically close name was selected intentionally > to show that these exchanges are related. However, I'm not a native > speaker and not always can realize how good or bad this similarity > sounds for a native ear. > > So, my question to WG - do we need to change the name? If yes, > then to what? Possible variants - IKE_INT (intermediate), IKE_PRE_AUTH. > Something else? > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 12 13:29:11 2018 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 801A9130D7A for ; Mon, 12 Nov 2018 13:29: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.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 xFxtgDQ-0_K4 for ; Mon, 12 Nov 2018 13:29:07 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 62B34128D68 for ; Mon, 12 Nov 2018 13:29:07 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id c206so2908106oib.0 for ; Mon, 12 Nov 2018 13:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPMvguA6WJ3VG7ki6Crw6DXA9fWJVkO1abuoKzpzhU0=; b=gECuUxdIcE0nO5M9lh3r6qT9IlwBfGwzaoTCLjF8OI8xpDnXvAEpsj9e1EhxJ4ELf+ u0qL4MvflQLqWxasLRBAVasU/RRpS0nWV6Ok0/aMA33ge/hZKNZtmIgLXW54QYzZSXYn xq6rvZ4eVlIpTrZFtlNr0quR3PjV1UUjk739f5MsjqmQgsVXOSZZVCkwQU/67ldkz1ZA 8OX4tR6Mp5WZH1kO6MKLCktb4FyKbQUTlAHeG+0IqsYREOp2iU3+WJCO/3T0n6T/wiXD j2TyIcolQRcqVtbY0gkd+GDr+6vyTa3KfCc3LEnboDm6SewlWwQFkKPAJbqSSb8So7iX imiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPMvguA6WJ3VG7ki6Crw6DXA9fWJVkO1abuoKzpzhU0=; b=WOI8+uT47lrB1kilYJqEPnVtHDhnRHF67O3Z0OTXMRWuslartEWj3wsniTENPXwE7P IbDp0GrHpNtumA9/PLR4rBTFbvoPLa5UlBXAiFrYropjIV3QLBCclv8OpKE+rBaKiLzO kMzhQ69Ux6eATsBtlHcSANJ28NGbUEPpmpSsn4xPOQGytombFGwyGqUqKG2Ba7vSStBh K41TUbi/64I0e6WBqr1b8EXDGeqx4AES6IAmvkFdj8uqKQuUKAqxLcMC6uAeGBzTbeG2 +yo+eSC4uSW0BkKXvoMA7xCWQXMa1hTusNLLy1J0w/fWhOB6lq9BYBDtCrrbBm8/wCa7 a5Cg== X-Gm-Message-State: AGRZ1gJcqmCtKP0rkl+DVkdHqWXhElT/S66t4R4o6tvIFkxT+i6bcNZm mfO6MJj0wYcKJB/zacnlZ4wU5RKWMoNr5YlrCx5iyMVj2IA= X-Google-Smtp-Source: AJdET5dzVnykBRh5J4w4BY/yz0uIq1Egsl0AhvkOoyafVrgzxRlZkk4B8wq6wWNmFn/5i/xLNDX1eyX1YrQKyqMh1M8= X-Received: by 2002:aca:c650:: with SMTP id w77mr1350126oif.122.1542058146695; Mon, 12 Nov 2018 13:29:06 -0800 (PST) MIME-Version: 1.0 References: <003b01d47a91$06b04950$1410dbf0$@gmail.com> In-Reply-To: From: CJ Tjhai Date: Mon, 12 Nov 2018 21:28:55 +0000 Message-ID: To: tpauly@apple.com Cc: Valery Smyslov , ipsec@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [IPsec] Rename IKE_AUX? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 21:29:09 -0000 How about IKE_SUP or IKE_SUPP (for IKE_SUPPLEMENTARY)? On Mon, 12 Nov 2018 at 21:14, Tommy Pauly wrote: > > I agree that IKE_AUX can be easily confused with IKE_AUTH. Similarly, IKE_INT looks a lot like the INIT from IKE_SA_INIT. > > I don't necessarily love IKE_PRE_AUTH, but it still seems preferable to the other options. You could also spell out "intermediate" to have IKE_INTERMEDIATE. This is still shorter than other existing exchange types, like IKE_SESSION_RESUME. > > Thanks, > Tommy > > > On Nov 12, 2018, at 6:07 AM, Valery Smyslov wrote: > > > > Hi, > > > > I'm going to update IKE_AUX draft (in particular - change the way > > it is authenticated based on recent discussion with Scott). > > > > I recall that there were some complaints that the name IKE_AUX > > is not good because it can easily be mixed up with IKE_AUTH > > Actually, the phonetically close name was selected intentionally > > to show that these exchanges are related. However, I'm not a native > > speaker and not always can realize how good or bad this similarity > > sounds for a native ear. > > > > So, my question to WG - do we need to change the name? If yes, > > then to what? Possible variants - IKE_INT (intermediate), IKE_PRE_AUTH. > > Something else? > > > > Regards, > > Valery. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 12 20:59:34 2018 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 CB43D129C6B for ; Mon, 12 Nov 2018 20:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 Xc7PprjoHg82 for ; Mon, 12 Nov 2018 20:59:29 -0800 (PST) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90119.outbound.protection.outlook.com [40.107.9.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3340C124408 for ; Mon, 12 Nov 2018 20:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+WqEqoTnNUAUUB+r3JVhsMc5wP0CCWvXc+aWxPsR498=; b=VAX437uul2MHLvZ4O2bvfc9pzyWOOQHI/1UAvycG1Yov1qz2LtUqzCK0CSlUDa5GQiZPmFJbvp6ojzE5p8HxtymkSXUt86mnQruD0tC3forgyXUuXx1A/WzNjsL38KU614i3E7eon9E48K44QD9q+BdIe5d9Aa+NhZ47xUZGenI= Received: from PR1PR07MB5755.eurprd07.prod.outlook.com (20.177.210.161) by PR1PR07MB5737.eurprd07.prod.outlook.com (20.177.210.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.14; Tue, 13 Nov 2018 04:59:26 +0000 Received: from PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::e501:ccf1:8866:9eee]) by PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::e501:ccf1:8866:9eee%2]) with mapi id 15.20.1339.019; Tue, 13 Nov 2018 04:59:26 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: CJ Tjhai , "tpauly@apple.com" CC: "ipsec@ietf.org" , Valery Smyslov Thread-Topic: [IPsec] Rename IKE_AUX? Thread-Index: AQHUes7HpkjHFd7dEUqDrqmkz+3M+KVNJXBQ Date: Tue, 13 Nov 2018 04:59:26 +0000 Message-ID: References: <003b01d47a91$06b04950$1410dbf0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-originating-ip: [2601:646:8780:b0d4:74f3:4934:65e8:5255] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PR1PR07MB5737; 6:MSUZN2YvHOUyxVa56Y3aUnvb7eMsCoOpSEOTedrcLBYWWxGB8yhKhGCyNV8ZsqIKm4gPro/I281D4Qf3faJfzfqwfV+6YtAI+LsPUQ41N9jxjnVmTLUKoRKYbaSy72i/nWA00j6p/d08ypuPEE2imKUTemuWKeSN5aI8p57IdEuBtHGxEYB3owkP9lPj5Ev88ozNNr5vgTW9kg7Trcixfl9sElI6IBeYYLc8dZmv8k3cwAUGAT/NuVVH1EolPniUSRYAgyvLQL+cj20w09Vs5jrl/RDWT8cQHXRWiT78/hJZzBXN+bRajdXXUbo7XVQOdE3AmNfEMFGwmyQd600dQezkvSuxbv/+EznV2w+dWEgVMPWRG9G6ZxtPKooqSOAgI5bS9gXa/GNmEtTe+jAGA7lZF6FVwAu/meb1gi5JjnmtAjvOy0yyJeHDh6VdwCcC7aTDUXANk1VtEP79fbYHxg==; 5:T3JBzy2OZ0aV+VIMOjW9gXQ/GhRQ/w4Kssff7xVk73u2vO3v5tGMS13HJES16MPOeoHepwthEOcX8hQZ2k9/TO9e3sPnCAirODdINlCm3LNgWzsTXL/QS+7NKjY17CT0KhHztArZNwlxlEvVAJJJo5zJiLszuNH+aPQ0QsqZlIs=; 7:v4FrU8OxAXTJTnyme7bzePqpNmQIYm5pM5ecoV9zTwPjh7XUFmr70B+AZS6r0t0rrognc9S2UKQBnqeN4HsEfRujmNsAHThthOXSoQrAvd/EJFOwChPzJYaOr0imOf+ImBqhG5iNL+wl/UHo33kIHA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 70a35f3c-d9f4-42bf-528d-08d64924c97b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:PR1PR07MB5737; x-ms-traffictypediagnostic: PR1PR07MB5737: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231382)(11241501184)(806099)(944501410)(52105112)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:PR1PR07MB5737; BCL:0; PCL:0; RULEID:; SRVR:PR1PR07MB5737; x-forefront-prvs: 085551F5A8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(396003)(136003)(366004)(13464003)(199004)(189003)(68736007)(5660300001)(46003)(7736002)(11346002)(2906002)(446003)(476003)(14444005)(256004)(486006)(4326008)(71190400001)(39060400002)(71200400001)(81156014)(8676002)(55016002)(6246003)(9686003)(2900100001)(81166006)(6306002)(106356001)(105586002)(86362001)(53936002)(6116002)(6506007)(186003)(478600001)(110136005)(97736004)(54906003)(2501003)(33656002)(316002)(25786009)(102836004)(53546011)(99286004)(8936002)(966005)(76176011)(7696005)(305945005)(74316002)(229853002)(6436002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5737; H:PR1PR07MB5755.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: B3NwO8plj1I1Fg6PAU6dv1P04C+28o4+GjZUGthazmevrqo2jBjUL++pJB1iTZcawFS2Q/SPSY9RlGPiucyal7Jhae/DIRrpp6F0p55/7sGrlftUtOKVH2X3G1kThWKuwToNUNYFc4KEUKZrcV59mw3k1DkpChHgjtUfrmIFOxuFo93j1xSNmI2CAzZSEdskoe8BJCEnmNIP0rPx4X/Dh1Xj8N9ovMM2xZ6MsMBvAt4w67iNv3A1MZb49TQc3JoQ0g1lVTeQlurf/VZLPF/6ppU9nWIbom/e4PT89tUMxP/GrpTGVxFnDsILE4uxQFcabqI6+8R7OOL3vwBwR01Ro0PP3wC/EW13kha3HNj8WIg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70a35f3c-d9f4-42bf-528d-08d64924c97b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 04:59:26.6831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5737 Archived-At: Subject: Re: [IPsec] Rename IKE_AUX? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 04:59:32 -0000 I think IKE_SUPP is better compare to what have mentioned=20 -----Original Message----- From: IPsec On Behalf Of CJ Tjhai Sent: Monday, November 12, 2018 1:29 PM To: tpauly@apple.com Cc: ipsec@ietf.org; Valery Smyslov Subject: Re: [IPsec] Rename IKE_AUX? How about IKE_SUP or IKE_SUPP (for IKE_SUPPLEMENTARY)? On Mon, 12 Nov 2018 at 21:14, Tommy Pauly wrote: > > I agree that IKE_AUX can be easily confused with IKE_AUTH. Similarly, IKE= _INT looks a lot like the INIT from IKE_SA_INIT. > > I don't necessarily love IKE_PRE_AUTH, but it still seems preferable to t= he other options. You could also spell out "intermediate" to have IKE_INTER= MEDIATE. This is still shorter than other existing exchange types, like IKE= _SESSION_RESUME. > > Thanks, > Tommy > > > On Nov 12, 2018, at 6:07 AM, Valery Smyslov wr= ote: > > > > Hi, > > > > I'm going to update IKE_AUX draft (in particular - change the way it=20 > > is authenticated based on recent discussion with Scott). > > > > I recall that there were some complaints that the name IKE_AUX is=20 > > not good because it can easily be mixed up with IKE_AUTH Actually,=20 > > the phonetically close name was selected intentionally to show that=20 > > these exchanges are related. However, I'm not a native speaker and=20 > > not always can realize how good or bad this similarity sounds for a=20 > > native ear. > > > > So, my question to WG - do we need to change the name? If yes, then=20 > > to what? Possible variants - IKE_INT (intermediate), IKE_PRE_AUTH. > > Something else? > > > > Regards, > > Valery. > > > > _______________________________________________ > > 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 From nobody Mon Nov 12 21:19:57 2018 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 BDC7D130DD3 for ; Mon, 12 Nov 2018 21:19:56 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 8KMfzlK2kFv6 for ; Mon, 12 Nov 2018 21:19:55 -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 B012A130DCF for ; Mon, 12 Nov 2018 21:19:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42vGCY28M0zF6Y; Tue, 13 Nov 2018 06:19:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542086393; bh=7c2ahmgF95zMA4CdAiW2Qi6010k1wJD9eptJh+//VQY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=s4vd0Y2leoccJlw2nJkeKDSIR3p+RzWsb7I0LKRotn42tODxf3bCv60R+nFjKw7v+ /sGrm+n3ZkhfYNUqZgCGQyqcb+XZauC6EYIWaMZ3JkbxSt5xFzPZqkGe0WxmDUn0tf 6skiSkwCPvkj1IdKfy794xwNYIm95zWSYoeY55Xc= 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 wdPEZ3NtKeL2; Tue, 13 Nov 2018 06:19:52 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Nov 2018 06:19:51 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4535319409; Tue, 13 Nov 2018 00:19:50 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B4535319409 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A770741C3B22; Tue, 13 Nov 2018 00:19:50 -0500 (EST) Date: Tue, 13 Nov 2018 00:19:50 -0500 (EST) From: Paul Wouters To: "Hu, Jun (Nokia - US/Mountain View)" cc: CJ Tjhai , "tpauly@apple.com" , "ipsec@ietf.org" , Valery Smyslov In-Reply-To: Message-ID: References: <003b01d47a91$06b04950$1410dbf0$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Rename IKE_AUX? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 05:19:57 -0000 Some other bike shed colours IKE_INIT_C - Init Continued IKE_INIT2 IKE_BE - Blob Exchange, Bulk Exchange IKE_LARGE IKE_BULK IKE_BIG_KE IKE_LARGE_KE I think IKE_SA_INIT is misnamed and should have been IKE_INIT, or IKE_AUTH should have been IKE_SA_AUTH :) I don't like IKE_CONT[INUE] because it might imply something after IKE is done. Similarly for IKE_SUPP is is midleading that it might be something in supplement of IKE. The same is true for IKE_AUX. But I don't care that much, just pick one. I don't object strongly to any name mentioned so far. I rather see people reading the whole draft carefully :) Paul From nobody Tue Nov 13 23:56:27 2018 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 9C4D61293FB for ; Tue, 13 Nov 2018 23:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 3D0PJjzfn9Q8 for ; Tue, 13 Nov 2018 23:56:24 -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 842F7130DD9 for ; Tue, 13 Nov 2018 23:56:23 -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 wAE7u2ah009225 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Nov 2018 09:56:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAE7u1DH001410; Wed, 14 Nov 2018 09:56:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23531.54545.136222.41944@fireball.acr.fi> Date: Wed, 14 Nov 2018 09:56:01 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'David Schinazi'" , ipsec@ietf.org In-Reply-To: <032c01d47724$f906d6d0$eb148470$@gmail.com> References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <032c01d47724$f906d6d0$eb148470$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 38 min Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 07:56:27 -0000 Valery Smyslov writes: > Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP? I would say that is better approach. I.e., ignore NO_NATS_ALLOWED and NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP o receiver when connection comes in with TCP. There is nothing we want to do even if detected NAT on the tcp path, we are not going to switc to switch to another port, we are not going to allow dynamic updates (as they would not work with TCP anyways), there is no point of sending keepalives on TCP etc. So on tcp just ignore those payloads. > I think that in general the co-existence of MOBIKE and TCP must be > elaborated in more detail in the draft. I agree. There are also several cases where we some of the mobike processing does not really make sense. Things like return routability checks, changing nat mappings, etc. The initial UPDATE_SA_ADDRESSES should be enough to just say that use this connection for return traffic. I do not think there is anything else for the responder to do for it. > > request. Probably we could clarify in TCP guidelines draft that the content > of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? Modifying the packet after it has been sent over any transport once, is impossible, and will break things. I.e., if client send packet using UDP and it did reach the destination correctly, but return packet got lost, and then client decided to move to TCP, and resend the packet. If the packet is modified, then responder will see it as an attack, as it is using message-id that where it has already processed and responded to, but the content of the frame is not same. As the content is not same, it will not retransmit its reply, so both ends just stop and finally the connection times out. >From the RFC7296 section 2.1: A retransmission from the initiator MUST be bitwise identical to the original request. That is, everything starting from the IKE header (the IKE SA initiator's SPI onwards) must be bitwise identical; items before it (such as the IP and UDP headers) do not have to be identical. That is the reason why mobike for example does the processing so that if it needs to change address during UPDATE_SA_ADDRESSES it will not modify packet it is sending out, it will simply run the process to end, and then redo it again from the start. It needs to do if it ever used more than one address, regardless which of them succeeded. I.e., if it send UPDATE_SA_ADDRESSES using source IP1 and does not get reply, moves to IP2, does not get reply, moves back IP1, and now do get reply, it still needs to do UPDATE_SA_ADDRESSES again because it did not know which of his frames got to the other end. It could have been that first packet ever reaching responder was sent from IP2, but the reply got lost, and then when initiator resent the packet from IP1, the responder just repeated the reply generated earlier packet from IP2... -- kivinen@iki.fi From nobody Wed Nov 14 00:55:52 2018 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 3C859130DF3 for ; Wed, 14 Nov 2018 00:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 LCRNXIBGbMwO for ; Wed, 14 Nov 2018 00:55:49 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 9EEF6130DC5 for ; Wed, 14 Nov 2018 00:55:48 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id p86so10938836lfg.5 for ; Wed, 14 Nov 2018 00:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=MV/UTNYf7t8HK4M8m4NW5yUpfaoeiQcqFDIINZi6OzA=; b=gjsh+Smtn3ruUSyQAMnOLho1IWklOGlOOu22cMHm9omSmF93ipqBRX2zGOhuIZoQde oncIrTVkqR5ESdWyhBljB0L97cmPSAaoqBlMpBYUA174N7gaNxkVA0EoZDwUah+DHMjM QdozT1eHtkLjhptZ+0wyBoeux1HckF0NokgF9BpASrT4kz7Ny8niX3Dt4iEB0wiDTNvd b4XhPfjobcGEhjnNZxlGwDwKvftKgTNDgEZVJAPMLQ8j70av1Y8jgOGXIYMAFueClk0J LKXWl3tciaHJX1WTaprtWlv5KoF8m67nO0n8Dt29IMNV2oaCrTP39uWmPfXBlmymKWLs LWyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=MV/UTNYf7t8HK4M8m4NW5yUpfaoeiQcqFDIINZi6OzA=; b=U83gt7e7RfZqQbVa5IBs7kBPxT/FNf2zbXv9IDPtVtyabvUkUj9d++4oJ2VJ/A5/ns 7SfHQVq+mHaztBV2N5yW7hWo+nf8RJtgZEjblE8i2tkyqTW+y/NJ0LmXcxiHw0eEzrNO kVHL3M4hTtKjoj2zrveND8nmbWt2R5Bl3twe8Llfd/0oWR4YeWA44DV63o5+oDrgb24+ YfCs5lLMmAzXa8v9PygtnuL2Ehn0bf7AuBlUSSxk6pKvIJOXhtv+6TjzEEvHYfBRZi4f vsc9Qw4hN/pwpnM5X+d5bKVy0G6VTsGXtuB4+JSNxge6aq1mCmtvPbAlrjOx4RKBRr5H iiCw== X-Gm-Message-State: AGRZ1gKrjMq8hUxDngvaK5b2S9gKtEDl1kRbx0IlwmXnLAgDbtslzHH3 kxAuvKsp1OMNnivjrkkeBFs= X-Google-Smtp-Source: AJdET5eFKwRf726eLtn7u9q5s4v8kZ8MJUFcebgZUEW1kxPgMN6WHuTphOE0Us+WPBkTd9vBNbjJ4A== X-Received: by 2002:a19:7399:: with SMTP id h25mr579350lfk.85.1542185746459; Wed, 14 Nov 2018 00:55:46 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y81-v6sm579279lje.30.2018.11.14.00.55.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Nov 2018 00:55:45 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'David Schinazi'" , References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <032c01d47724$f906d6d0$eb148470$@gmail.com> <23531.54545.136222.41944@fireball.acr.fi> In-Reply-To: <23531.54545.136222.41944@fireball.acr.fi> Date: Wed, 14 Nov 2018 11:55:44 +0300 Message-ID: <01db01d47bf7$d4e34630$7ea9d290$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINC5x2IttgBeVJM8GBpgLrp7BrywFkiMAmAUp58kMBQ1c7HqS+N/zA Content-Language: ru Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 08:55:51 -0000 Hi Tero, > > Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP? > > I would say that is better approach. I.e., ignore NO_NATS_ALLOWED and > NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP o receiver > when connection comes in with TCP. > > There is nothing we want to do even if detected NAT on the tcp path, > we are not going to switc to switch to another port, we are not going > to allow dynamic updates (as they would not work with TCP anyways), > there is no point of sending keepalives on TCP etc. > > So on tcp just ignore those payloads. Makes sense. > > I think that in general the co-existence of MOBIKE and TCP must be > > elaborated in more detail in the draft. > > I agree. There are also several cases where we some of the mobike > processing does not really make sense. Things like return routability > checks, changing nat mappings, etc. The initial UPDATE_SA_ADDRESSES > should be enough to just say that use this connection for return > traffic. I do not think there is anything else for the responder to do > for it. The uselessness of the return routability check in case of TCP is already mentioned in the draft. > > request. Probably we could clarify in TCP guidelines draft that the content > > of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? > > Modifying the packet after it has been sent over any transport once, > is impossible, and will break things. > > I.e., if client send packet using UDP and it did reach the destination > correctly, but return packet got lost, and then client decided to move > to TCP, and resend the packet. > > If the packet is modified, then responder will see it as an attack, as > it is using message-id that where it has already processed and > responded to, but the content of the frame is not same. As the content > is not same, it will not retransmit its reply, so both ends just stop > and finally the connection times out. Depending on the implementation, the content in this case might not be checked, the latest response might just be sent. There is no point to re-check the content of the replayed packet, it's only waste of CPU resources. > >From the RFC7296 section 2.1: > > A retransmission from the initiator MUST be bitwise identical to > the original request. That is, everything starting from the IKE > header (the IKE SA initiator's SPI onwards) must be bitwise > identical; items before it (such as the IP and UDP headers) do not > have to be identical. > > That is the reason why mobike for example does the processing so that > if it needs to change address during UPDATE_SA_ADDRESSES it will not > modify packet it is sending out, it will simply run the process to > end, and then redo it again from the start. It needs to do if it ever > used more than one address, regardless which of them succeeded. I.e., > if it send UPDATE_SA_ADDRESSES using source IP1 and does not get > reply, moves to IP2, does not get reply, moves back IP1, and now do > get reply, it still needs to do UPDATE_SA_ADDRESSES again because it > did not know which of his frames got to the other end. It could have > been that first packet ever reaching responder was sent from IP2, but > the reply got lost, and then when initiator resent the packet from > IP1, the responder just repeated the reply generated earlier packet > from IP2... These exchanges (trying out IP1, IP2 etc.) will have different Message IDs anyway (*). So the responder won't reply with previously saved response, because Message IDs will differ. And the content of NAT_DETECTION_*_IP can be recalculated accordingly (*) From RFC 4555: If the request to update the addresses is retransmitted using several different source addresses, a new INFORMATIONAL request MUST be sent. Anyway, I agree that the current exchange must be finished off (either completed or deemed timed out) before a new one is started from (to) a different IP. But with TCP we don't change address, we only change transport, so the exchange must remain the same when switching from UDP to TCP... And this would break some things, like NO_NATS_ALLOWED and NAT_DETECTION. Regards, Valery. > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Nov 14 18:24:09 2018 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 0D556130DF9 for ; Wed, 14 Nov 2018 18:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 M-ASG44jzBSs for ; Wed, 14 Nov 2018 18:24:05 -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 D907B130E0C for ; Wed, 14 Nov 2018 18:24:01 -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 wAF2NfQM018103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Nov 2018 04:23:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAF2NeEP011435; Thu, 15 Nov 2018 04:23:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23532.55468.578150.420475@fireball.acr.fi> Date: Thu, 15 Nov 2018 04:23:40 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'David Schinazi'" , ipsec@ietf.org In-Reply-To: <01db01d47bf7$d4e34630$7ea9d290$@gmail.com> References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <032c01d47724$f906d6d0$eb148470$@gmail.com> <23531.54545.136222.41944@fireball.acr.fi> <01db01d47bf7$d4e34630$7ea9d290$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 23 min X-Total-Time: 1041 min Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 02:24:08 -0000 Valery Smyslov writes: > > If the packet is modified, then responder will see it as an attack, as > > it is using message-id that where it has already processed and > > responded to, but the content of the frame is not same. As the content > > is not same, it will not retransmit its reply, so both ends just stop > > and finally the connection times out. > > Depending on the implementation, the content in this case might > not be checked, the latest response might just be sent. Could be, but there are implementations which do the check (or actually check that the hash of the incoming packet is same, they might not store the whole original packet). And this is something that is clearly allowed in the RF7296, as request must be bitwise identical. > There is no point to re-check the content of the replayed > packet, it's only waste of CPU resources. You do open yourself of (semi) blind reflection attacks if you do not check the frame. I.e., someone might send 28 byte empty IKEv2 packets having correct SPI and message ID, and cause you to resend much larger result. If you do check the incoming frame attacker needs to see original frame, and needs to also send as big packet than original sender sent. CPU is cheap, transmission of frames is more costly. > > >From the RFC7296 section 2.1: > > > > A retransmission from the initiator MUST be bitwise identical to > > the original request. That is, everything starting from the IKE > > header (the IKE SA initiator's SPI onwards) must be bitwise > > identical; items before it (such as the IP and UDP headers) do not > > have to be identical. > > > > That is the reason why mobike for example does the processing so that > > if it needs to change address during UPDATE_SA_ADDRESSES it will not > > modify packet it is sending out, it will simply run the process to > > end, and then redo it again from the start. It needs to do if it ever > > used more than one address, regardless which of them succeeded. I.e., > > if it send UPDATE_SA_ADDRESSES using source IP1 and does not get > > reply, moves to IP2, does not get reply, moves back IP1, and now do > > get reply, it still needs to do UPDATE_SA_ADDRESSES again because it > > did not know which of his frames got to the other end. It could have > > been that first packet ever reaching responder was sent from IP2, but > > the reply got lost, and then when initiator resent the packet from > > IP1, the responder just repeated the reply generated earlier packet > > from IP2... > > These exchanges (trying out IP1, IP2 etc.) will have different > Message IDs anyway (*). No they do not. They have all same Message ID, as you can only send one frame out at time if using window size 1, so you need to wait for response for message you sent out before you can modify it and send another frame out. > So the responder won't reply with previously saved response, because > Message IDs will differ. And the content of NAT_DETECTION_*_IP can > be recalculated accordingly > > (*) From RFC 4555: > If the request to update the addresses is retransmitted using several > different source addresses, a new INFORMATIONAL request MUST be sent. Yes, this means that we need to start new exchange AFTER the one we are doing now finished. It does not mean that while we sent frame out using different source IP addresses used different message IDs. I.e., the exchange is as follows: Initiator Responder --------- --------- (IP_I1:500 -> IP_R1:500, MID=12I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> (IP_I1:500 -> IP_R1:500, MID=12I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> (IP_I2:500 -> IP_R1:500, MID=12I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> (IP_I2:500 -> IP_R1:500, MID=12I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> (IP_I1:500 -> IP_R1:500, MID=12I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> <-- (IP_R1:500 -> IP_I1:500, MID=12R) HDR, SK { N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } Now, the UPDATE_SA_ADDRESSES is done, but as the request used multiple IP addresses the initiator needs to redo it: Initiator Responder --------- --------- (IP_I1:500 -> IP_R1:500, MID=13I) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } --> <-- (IP_R1:500 -> IP_I1:500, MID=13R) HDR, SK { N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } > Anyway, I agree that the current exchange must be finished off > (either completed or deemed timed out) before a new one is started > from (to) a different IP. It MUST be finished, which is why you use all possible IP address pairs for that ONE exchange before you decide it failed. If it failed, you delete the IKE SA, and you cannot start any exchange on different IP after that for that IKE SA, as there is no longer IKE SA you could use. See RFC4621 section 6.2 for more datails. > But with TCP we don't change address, we only change transport, so > the exchange must remain the same when switching from UDP to TCP... > And this would break some things, like NO_NATS_ALLOWED and > NAT_DETECTION. It is exactly same for MOBIKE with UDP. NAT detection, IP addresses used etc can be wrong after the UPDATE_SA_ADDRESSES, and the initiator MUST detect thiss possibility, and redo the UPDATE_SA_ADDRESSES so that they will get fixed. Initiator is responsible to try to fix this until it gets exchange through in a way there cannot be issues which frame was acted on in the responder, i.e., it MUST ensure that initiator and responder stays in sync. In tcp encapsulation the situation is same. Once we move to TCP, or from TCP to UDP, that is deteced by the initiator that something changed during UPDATE_SA_ADDRESSES, so after that exchange finishs successfully, it needs to redo it using the path it thinks work, and verify that both ends are in sync. -- kivinen@iki.fi From nobody Wed Nov 14 23:13:08 2018 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 62B8612872C for ; Wed, 14 Nov 2018 23:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 SAap-IUPYq1j for ; Wed, 14 Nov 2018 23:13:04 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 3E772127B92 for ; Wed, 14 Nov 2018 23:13:04 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id g11-v6so3740211ljk.3 for ; Wed, 14 Nov 2018 23:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=D+t2YU9jAkJZ2yq+uLEqr+m7NJ5rE6Tme4BQgqESYxQ=; b=NJ9G5g9uRVeSq4FkrlixLEV6jXhOA9u4sJF439dMNVud7zNeRtOJE230RUzD4GxLrT n8fhappnX24urrLG2jopczbaB74nM806ncb9BAKt/me3ZhSEz4VYXwwzk8Pv7btlVhns WFyCdRTOY3AdSEGZ9R7ibW51q4vPrpbc0RAepVXOafKGDvaTGMFwuPJZU2rZfaziGpMu dGc1x9R70ozi91MtH4rR5RChREK3YbikHaSdAlaKXHvY+sb5YBA2nO1yVUsgQ2YwHUU5 MiwgVjPtKHeeLm6SQfwKjfchDTMY3l5qWM2sizxKwuBBZ3le0W7DqhY5efGinoDRzKs1 gBYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=D+t2YU9jAkJZ2yq+uLEqr+m7NJ5rE6Tme4BQgqESYxQ=; b=XXRCoIPcFFSKWffrk0VXUBrkt+OHm3PzgnBRvyhnzxmXOQ4XVDRN3BopBRRSM8Pc8g nkjyFoEHyGJfbkO4axULYHDdj76KBd6ejbg69sIScCKngNL9RPJBwzsl2YjWG4uKPT3V tjqy4ykL77AynLeydUtURO92I9ZM3/ng9UORpzOq1uHBkhNXYGHNHyEnJmvWIyfWs+lU g23SDUOiD6EQPUizKM3qwKuysBasRQhvN6W3xpeTPcO2tGMTH4cqJPMOE0opK4248ET9 /xrc5jBQYP71w1sbJfZFX13R/n/7+EvNubhMSJTbhEkjj8CksfGft4pDgoPBDMWNE1fV ISRw== X-Gm-Message-State: AGRZ1gJUgOYISXhSLXqXJU9/UQk5fghwh8UqprsBC4/TNLqrNI+dGFLF ndYF/qB+USOUXvJh7B4QsGw= X-Google-Smtp-Source: AJdET5fEKOwcTj7jUXSpnUjuFAPACk0/RnXjKkN5pBKd1kVxT6j47VL7Mz8yiDy6Lglb0XItWffTzA== X-Received: by 2002:a2e:5c86:: with SMTP id q128-v6mr3095168ljb.119.1542265982113; Wed, 14 Nov 2018 23:13:02 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q127-v6sm4661889ljq.45.2018.11.14.23.13.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Nov 2018 23:13:01 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'David Schinazi'" , References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <032c01d47724$f906d6d0$eb148470$@gmail.com> <23531.54545.136222.41944@fireball.acr.fi> <01db01d47bf7$d4e34630$7ea9d290$@gmail.com> <23532.55468.578150.420475@fireball.acr.fi> In-Reply-To: <23532.55468.578150.420475@fireball.acr.fi> Date: Thu, 15 Nov 2018 10:12:53 +0300 Message-ID: <006e01d47cb2$a0e40cf0$e2ac26d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINC5x2IttgBeVJM8GBpgLrp7BrywFkiMAmAUp58kMBQ1c7HgIefhUlAv8mnAyklry5MA== Content-Language: ru Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 07:13:06 -0000 > > There is no point to re-check the content of the replayed > > packet, it's only waste of CPU resources. > > You do open yourself of (semi) blind reflection attacks if you do not > check the frame. I.e., someone might send 28 byte empty IKEv2 packets > having correct SPI and message ID, and cause you to resend much larger > result. > > If you do check the incoming frame attacker needs to see original > frame, and needs to also send as big packet than original sender sent. It's much easier to rate limit responses, say no more than one per second. You may also check the length. > CPU is cheap, transmission of frames is more costly. True, but still doesn't justify wasting CPU. > > (*) From RFC 4555: > > If the request to update the addresses is retransmitted using several > > different source addresses, a new INFORMATIONAL request MUST be sent. > > Yes, this means that we need to start new exchange AFTER the one we > are doing now finished. It does not mean that while we sent frame out > using different source IP addresses used different message IDs. > > I.e., the exchange is as follows: > > Initiator Responder > --------- --------- > > (IP_I1:500 -> IP_R1:500, MID=12I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > (IP_I1:500 -> IP_R1:500, MID=12I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > (IP_I2:500 -> IP_R1:500, MID=12I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > (IP_I2:500 -> IP_R1:500, MID=12I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > (IP_I1:500 -> IP_R1:500, MID=12I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > <-- (IP_R1:500 -> IP_I1:500, MID=12R) > HDR, SK { N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } > > Now, the UPDATE_SA_ADDRESSES is done, but as the request used multiple > IP addresses the initiator needs to redo it: > > Initiator Responder > --------- --------- > > (IP_I1:500 -> IP_R1:500, MID=13I) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } --> > > <-- (IP_R1:500 -> IP_I1:500, MID=13R) > HDR, SK { N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP) } OK, that only justifies my thought that MOBIKE is fragile :-) What if both paths work, but the networks are lossy? In this case with high probability your second exchange will look like the first: you won't get reply on IP_R1, switch to IP_R2, got reply and initiate new exchange again. And so on. The process won't converge well. > > Anyway, I agree that the current exchange must be finished off > > (either completed or deemed timed out) before a new one is started > > from (to) a different IP. > > It MUST be finished, which is why you use all possible IP address > pairs for that ONE exchange before you decide it failed. If it failed, > you delete the IKE SA, and you cannot start any exchange on different > IP after that for that IKE SA, as there is no longer IKE SA you could > use. OK. > > But with TCP we don't change address, we only change transport, so > > the exchange must remain the same when switching from UDP to TCP... > > And this would break some things, like NO_NATS_ALLOWED and > > NAT_DETECTION. > > It is exactly same for MOBIKE with UDP. NAT detection, IP addresses > used etc can be wrong after the UPDATE_SA_ADDRESSES, and the initiator > MUST detect thiss possibility, and redo the UPDATE_SA_ADDRESSES so > that they will get fixed. Initiator is responsible to try to fix this > until it gets exchange through in a way there cannot be issues which > frame was acted on in the responder, i.e., it MUST ensure that > initiator and responder stays in sync. Not exactly. The MOBIKE currently is only concerned with IP addresses. It doesn't take transport into consideration. If you formally follow MOBIKE you don't need to initiate new exchange, because when you switch from UDP to TCP the IP will remain the same. > In tcp encapsulation the situation is same. Once we move to TCP, or > from TCP to UDP, that is deteced by the initiator that something > changed during UPDATE_SA_ADDRESSES, so after that exchange finishs > successfully, it needs to redo it using the path it thinks work, and > verify that both ends are in sync. Again, the path doesn't change, the transport changes. So, this must be clarified in the draft... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Nov 15 03:51:11 2018 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 CC75A124C04 for ; Thu, 15 Nov 2018 03:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 Gx-4_PqBrhgX for ; Thu, 15 Nov 2018 03:51:07 -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 3DC41124408 for ; Thu, 15 Nov 2018 03:51:07 -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 wAFBojFK008040 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Nov 2018 13:50:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAFBoj2H018059; Thu, 15 Nov 2018 13:50:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23533.23957.749071.182117@fireball.acr.fi> Date: Thu, 15 Nov 2018 13:50:45 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: "'David Schinazi'" , ipsec@ietf.org In-Reply-To: <006e01d47cb2$a0e40cf0$e2ac26d0$@gmail.com> References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <032c01d47724$f906d6d0$eb148470$@gmail.com> <23531.54545.136222.41944@fireball.acr.fi> <01db01d47bf7$d4e34630$7ea9d290$@gmail.com> <23532.55468.578150.420475@fireball.acr.fi> <006e01d47cb2$a0e40cf0$e2ac26d0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 23 min Archived-At: Subject: Re: [IPsec] TCP and MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 11:51:10 -0000 Valery Smyslov writes: > It's much easier to rate limit responses, say no more than one per second. > You may also check the length. True, but this is what some implementations did and perhaps do still. And the RFC7296 mandates that retransmission must be bitwise identical (there are other reasons for that too). > OK, that only justifies my thought that MOBIKE is fragile :-) > What if both paths work, but the networks are lossy? In normal cases you do bit more tries for the first IP, before you move to second or third. I.e., something like 5 retries on first address (0.5, 1, 2, 4, 8 second intervals using 15.5 seconds or first address), and then move to 2nd address and so on. > In this case with high probability your second exchange > will look like the first: you won't get reply on IP_R1, > switch to IP_R2, got reply and initiate new exchange again. > And so on. The process won't converge well. True. On the other hand you only need to succeed once to converge it, and you only need to do this if you have so bad connection that you really start timing out lots of request. In that case there will be other usage issues anyway.... > Not exactly. The MOBIKE currently is only concerned with IP addresses. > It doesn't take transport into consideration. If you formally follow MOBIKE > you don't need to initiate new exchange, because when you switch from > UDP to TCP the IP will remain the same. Not true. > > In tcp encapsulation the situation is same. Once we move to TCP, or > > from TCP to UDP, that is deteced by the initiator that something > > changed during UPDATE_SA_ADDRESSES, so after that exchange finishs > > successfully, it needs to redo it using the path it thinks work, and > > verify that both ends are in sync. > > Again, the path doesn't change, the transport changes. > So, this must be clarified in the draft... The rfc4555 does not defined path, but rfc4621 does: Path The sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire, they might be routed along a different path, for example, due to load balancing. This definition is taken from [RFC2960] and adapted to the MOBIKE context. So the transport protocol should be taken in to account. Unfortunately the section 1.3 do not refer to the rfc4621 for terminology, but I think it should have done that, as I think it defines other terms too (available address, current path etc). -- kivinen@iki.fi From nobody Thu Nov 15 17:17:30 2018 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 9767C123FFD; Thu, 15 Nov 2018 17:17:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2018 17:17:28 -0800 Archived-At: Subject: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 01:17:29 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting YES because I think this mechanism has significant value, but I do also have some substantial comments that will likely result in changes to the draft. (I also have a number of nit-level comments.) Section 1 nit: the Abstract and Introduction are supposed to stand on their own, so starting off with "Split DNS is a common configuration" before defining it makes the reader work a bit harder than perhaps they need to. Section 2 When Split DNS has been negotiated, the existing DNS server configuration attributes will be interpreted as internal DNS servers that can resolve hostnames within the internal domains. nit: maybe add a word or two to emphasize that the existing attributes are also IKEv2 Configuration Payload Attributes? Section 2.1 If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REQUEST, the initiator MUST also include one or more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST. nit: I think I could parse this as saying that I need one or more IP4 and also one or more IP6 attributes (i.e., precluding v4- or v6-only configurations), which I assume is not the intent. Maybe "or" or "and/or" would be better than "and"? To indicate support for DNSSEC, an initiator includes one or more INTERNAL_DNSSEC_TA attributes as defined in Section 3 as part of the CFG_REQUEST payload. [...] nit: There are perhaps philosophical arguments to have about whether this indicates support for DNSSEC as a whole, or just for receiving trust anchors for DNSSEC from the responder [for the split-DNS domain(s)]. Section 2.2 supported by the server, unless the initiator has been configured with local polict to define a set of Split DNS domains to use by default. typo: "policy" We have to use DNS presentation format for the DS records and not wire format? Section 2.4 Please consider using IPv6 examples, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ . Section 3.1 o Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", in DNS presentation format and optionally using IDNA [RFC5890] for Internationalized Domain Names. Implementors need to be careful that this value is not null-terminated. W.r.t. IDNA, is this an A-label or a U-label? W.r.t NUL-termination, do they need to not send the zero byte or not expect to receive one? Section 3.2 Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to the same domain name MUST be ignored and treated as a protocol error. Isn't "ignored" incompatible with "treated as a protocol error"? Section 4 If a client is configured by local policy to only accept a limited number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other INTERNAL_DNS_DOMAIN values. Is this a limited *number* or a limited *set*? (If the former, exposition about which ones are the "other" ones is probably in order.) private remote network using the IPsec connection. If all traffic is routed over the IPsec connection, the existing global INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating specific DNS exemptions. DNS or DNSSEC exemptions (i.e., both)? Section 5 DNS records can be used to publish specific records containing trust anchors for applications. The most common record type is the TLSA record specified in [RFC6698]. This DNS record type publishes which CA certificate or EE certificate to expect for a certain host name. These records are protected by DNSSEC and thus can be trusted by the application. [...] I'm probably thinking too much about "trust" as a concept (due to the RATS BoF), but especially given that this goes on to say that this is a local policy decision, I'd suggest replacing "can be trusted" with something like "has a trust path in" or "are trustable by". Merely being in DNS with valid DNSSEC signatures does not make the client trust it; that's still a local policy decision. It allows the remote IKE/IPsec server to modify DNS answers including its DNSSEC cryptographic signatures by overriding existing DNS information with trust anchor conveyed via IKE and (temporarilly) installed on the IKE client. [...] nits: "including DNSSEC cryptographic signatures" (no "its"); "trust anchor(s)" IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains that can be updated out of band. IKE clients with an empty whitelist MUST NOT use any INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- whitelisted domain as an indication that their local configuration may need to be updated out of band. [...] IKE clients MAY interpret an INTERNAL_DNSSEC_TA for domain that was not preconfigured as an indication that it needs to update its IKE configuration (out of band). The client MUST NOT use such a INTERNAL_DNSSEC_TA to reconfigure its local DNS settings. These two paragraphs seem essentially redundant (the first seems better to me). IKE clients MUST ignore any received INTERNAL_DNSSEC_TA requests for a FDQN for which it did not receive and accept an INTERNAL_DNS_DOMAIN Configuration Payload. nit: are these really "requests"? Section 6 It's probably appropriate to reiterate here that "As discussed in Section 5, the INTERNAL_DNSSEC_TA mechanism allows the credential used to authenticate an IKEv2 association to be leveraged into authenticating credentials for TLS and other connections. This reflects something of a privilege escalation, and initiators should ensure that they have sufficient trust in the communications peer to responsibly use (or not use) that elevated privilege." If the initiator is using DNSSEC validation for a domain in its public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure its DNS resolver to allow for an insecure delegation. It SHOULD NOT accept insecure delegations for domains that are DNSSEC signed in the public DNS view, for which it has not explicitely requested such deletation by specifying the domain specifically using a INTERNAL_DNS_DOMAIN(domain) request. It seems like heeding this SHOULD NOT would potentially require the initiator to make extra DNS requests from the external view that it would not otherwise need to make. I agree that this is the behavior we want to encourage with respect to not downgrading away from DNSSEC, but it's less clear to me that we want to encourage the initiator to go out of its way to check, as opposed to just using information it may happen to have already. From nobody Fri Nov 16 13:29:11 2018 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 D8B4D12007C; Fri, 16 Nov 2018 13:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 xIHKckF-1usa; Fri, 16 Nov 2018 13:28:59 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840105.outbound.protection.outlook.com [40.107.84.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80FA127332; Fri, 16 Nov 2018 13:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rQNlWN0LbUwTtRKn2eRxaoC2PXKTHBpcPsELo02NObo=; b=W3EKwdhfAH7ypk1xhDTeFmsREcVSeg/Qj7Bp9Oa71z4kmVdhcH174WnE/j1y+Wv9unYU5OtIL4sSUbfhO4nzNmChI4L9ZjCQyuw3S03AECSqTodkC60so+T25M47iV8vmy94qGQQU4+cMV+BkVdI33wPJLM7kM1TnNiKDlsHEkY= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3261.namprd09.prod.outlook.com (20.177.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.23; Fri, 16 Nov 2018 21:28:54 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::6551:3ad2:eea0:8080]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::6551:3ad2:eea0:8080%5]) with mapi id 15.20.1339.021; Fri, 16 Nov 2018 21:28:54 +0000 From: "Waltermire, David A. (Fed)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-ipsecme-split-dns@ietf.org" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" Thread-Topic: Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) Thread-Index: AQHUfUotpNKLOyDJ4UeRIV78y/cJhaVS6paw Date: Fri, 16 Nov 2018 21:28:54 +0000 Message-ID: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> In-Reply-To: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR09MB3261; 6:FE526O9SCxeHr6noeTW23rnBLpj2uKy5dUYbRZ4zCoCYjl11NTVgGbSna9WDFOPcwuJxlxjNDotw7qiPtsE5TvgEpyiNUo76gfLVf/tsfDmEPCA517p2jnyrg4uoIclj4+lnr5zxuLi3IYSvDn1eFshdN6pQfHMXVZRyePsrHV1dYH3xThjE7xrEtWqzTQzEbeilJMvBvaMTH63IlI/rG7imi7DjIp2NC9ODuwPIwvOIYt4skkgLbJsW58wewt5iEmzJ5Bskj/t7p0lTuMJ9DNoQ7ioIL5n2Ka+bTfqq5M5f7YDayCkRU2TtwUxrU0uGtAMlNwuOwVCx6hDAotQV/pqxowLRU4Upx659SOECbmAATenjLO6cyY1D1hpifs/x/o1NE3i/NH6BWXBbSfbwIHsv1dK2ihJkWfhKz+y0XoWluP4OiDK9z/bJQoJTtKdWZkH5TRiK3ClEbuYSyf2YWw==; 5:2NLOKl/XkkuggQzNGJbWTSq8Sawmwj7eXI0Y2LnPD8StKS/pyZN75T4DJWra+a1Oeit4wYZ28jrnxJ/y1ilcTUlQUdpsBWXE0A4C8BPHUGgZcGwwI8gE06PEVa0kkqBHxzWgNgbHp5ybcSZRllkDAbhEvlVtAvdteW55xgmuPqQ=; 7:UTSAxkMi8IW/eCvFLW6svf50EpRky7Ew6W7eY64lAAbofx26mxe5tJGwZs9rsr5mL8KmBKpJBrHaiepcXW6bEIKfV55ReDx89Ygi6vEoy1jX3n4s3om6qEgT5Ou6mKCTnxzADCC/FEFWD9rmBnBtVw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b8587da3-87f6-45e2-6274-08d64c0a827a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR09MB3261; x-ms-traffictypediagnostic: SN6PR09MB3261: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231415)(944501410)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:SN6PR09MB3261; BCL:0; PCL:0; RULEID:; SRVR:SN6PR09MB3261; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(97736004)(106356001)(6506007)(71200400001)(71190400001)(102836004)(33656002)(105586002)(76176011)(7696005)(25786009)(66066001)(68736007)(26005)(186003)(8936002)(81166006)(2906002)(4326008)(8676002)(3846002)(14454004)(6116002)(99286004)(5660300001)(54906003)(110136005)(229853002)(316002)(6246003)(81156014)(2171002)(478600001)(6436002)(446003)(53936002)(476003)(305945005)(55016002)(9686003)(86362001)(2900100001)(486006)(256004)(7736002)(74316002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3261; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: mOCnfTW4UObBe1fcAeGxePGQTBaDi3CE/SOS7ziPXlnE/XmjOJ56GO8Fh7Wtzr7e0CjP4ttLyud3m7aSvAxoAIadU80rZpbtyyC1khVAChqw4wD65v/lZF86GCxOCvH+u1CUk/6aCjpzORkQoPa3HjFtIHTlIiHPJYf6bpYkQcfzNg9LBbc7v8M0Or6k2RyYT11dF3faGYwAmnVIj+il+vO5Hf05qMP7sl7fB0fVDa71iqh5xGZ/5X7WWVakTXDso0WfGQu4WZQw53S++gbJBugwJpYrG4IFKaOfcTIZnZ/MzB1Ccce+YFhnZTmhi63gYOJgv3xod8hTTaZFco1BJpXZqfPYSiIwEt1Zz8fTiF0= spamdiagnosticoutput: 1:99 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-Network-Message-Id: b8587da3-87f6-45e2-6274-08d64c0a827a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2018 21:28:54.1065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3261 Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 21:29:01 -0000 QmVuLA0KDQpPbmUgY29tbWVudCBvbiB5b3VyIENPTU1FTlQgd2VhcmluZyBjaGFpciBhbmQgc2hl cGhlcmQgaGF0czoNCg0KPiBXZSBoYXZlIHRvIHVzZSBETlMgcHJlc2VudGF0aW9uIGZvcm1hdCBm b3IgdGhlIERTIHJlY29yZHMgYW5kIG5vdCB3aXJlDQo+IGZvcm1hdD8NCg0KVGhlIGdyb3VwIHdh cyAic3BsaXQiIG9uIHRoaXMgcXVlc3Rpb24uIFdlIGRpZCBhIGh1bSwgd2l0aCBtb3N0IHJlc3Bv bmRpbmcgaW4gdGhlIHJvb20gdGhhdCB0aGV5IGVpdGhlciBkaWQgbm90IGNhcmUgb3IgaGFkIGEg c2xpZ2h0IHByZWZlcmVuY2UgZm9yIHByZXNlbnRhdGlvbiBmb3JtYXQuIFRoaXMgaXMgd2h5IGl0 IGlzIHRoaXMgd2F5Lg0KDQpSZWdhcmRzLA0KRGF2ZQ0KDQo= From nobody Fri Nov 16 14:41:10 2018 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 AEE00130E36; Fri, 16 Nov 2018 14:41:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154240806866.599.13215261386511762527@ietfa.amsl.com> Date: Fri, 16 Nov 2018 14:41:08 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 22:41:09 -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 WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-06.txt Pages : 8 Date : 2018-11-16 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-06 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 Fri Nov 16 22:15:21 2018 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 5BC98129619; Fri, 16 Nov 2018 22:15:11 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 p80O_Ocp95uv; Fri, 16 Nov 2018 22:15:09 -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 5E47E128CE4; Fri, 16 Nov 2018 22:15:09 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42xlFN5V7pz5Gb; Sat, 17 Nov 2018 07:15:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542435304; bh=SMYb7HDPTUzQzNYMk+gAJsbkcWQDHo20JguUEKkL4lM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SPetfXWr8cjmM2Q6+oHbBLTJQi8NmRINB03tuPZ577YraLu5ntcd+KHH7UdUycoP0 qPeLxa1x5Y+1joN6g7G9Ow8RCcaBlma7NjROK78WuUpRhMc++pqz9+xEQIr/tdPuDe RQmYus8WkGtJjbSIdKP1LUUlZGoxsCti6n37w1h8= 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 eG5toCw9XvfX; Sat, 17 Nov 2018 07:15:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 17 Nov 2018 07:15:01 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 214F74E18C0; Sat, 17 Nov 2018 01:15:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 214F74E18C0 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 151F641C3B2D; Sat, 17 Nov 2018 01:15:01 -0500 (EST) Date: Sat, 17 Nov 2018 01:15:01 -0500 (EST) From: Paul Wouters To: "Waltermire, David A. (Fed)" cc: Benjamin Kaduk , The IESG , "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "draft-ietf-ipsecme-split-dns@ietf.org" In-Reply-To: Message-ID: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 06:15:11 -0000 On Fri, 16 Nov 2018, Waltermire, David A. (Fed) wrote: > One comment on your COMMENT wearing chair and shepherd hats: > >> We have to use DNS presentation format for the DS records and not wire >> format? > > The group was "split" on this question. We did a hum, with most responding in the room that they either did not care or had a slight preference for presentation format. This is why it is this way. Note that we did not use humming as a vote. The humming gave an idea of the room that the disadvantage of IKE software needing to understand and convert wire to/from presentation format only to prevent "string overflow errors" was not worth the trouble of forcing a wire format, especially since IKE just relays this information to another application, and this API almost certainly uses presentation format (for example, unbound-control) Paul From nobody Sat Nov 17 09:40:58 2018 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 B14111252B7; Sat, 17 Nov 2018 09:40:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154247645671.15969.2304550137908278124.idtracker@ietfa.amsl.com> Date: Sat, 17 Nov 2018 09:40:56 -0800 Archived-At: Subject: [IPsec] Alexey Melnikov's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 17:40:57 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a well written document, so thank you for that. I've noticed that Benjamin already found typos that I found and raised one of the same questions, but I think this is important enough to be addressed before I recommend approval of this document. Specifically: In Section 3.1: o Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", in DNS presentation format and optionally using IDNA [RFC5890] for Internationalized Domain Names. Do you mean A-label or U-label form here? Implementors need to be careful that this value is not null-terminated. From nobody Sat Nov 17 22:53:19 2018 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 32828130D7A; Sat, 17 Nov 2018 22:53:18 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 19rE9jqWX3VS; Sat, 17 Nov 2018 22:53:13 -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 2991A126CB6; Sat, 17 Nov 2018 22:53:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42yN2m3d8Pz1GN; Sun, 18 Nov 2018 07:53:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542523984; bh=gFEJ33HyWhhNWfPzgwj6vn4FZu+HybZggrwyBr60Y0s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ldoA+HI6HStI6oPN9dqz6FBWzY0Wf8jNb+jWftOQKriH6/cO1wHV/2zi5Y7TZFnAg 503yC6vt8Jv63PUPSYSccdyEQEwwip1SYW7B4WerViB+LdN5oVHlqTrxzjUAq1RE4b tiVynx75tzjUdoekPSlAuS9sT2zlUvW3RYszGIgU= 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 NsObF41p8ZJR; Sun, 18 Nov 2018 07:53:00 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 18 Nov 2018 07:52:58 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 194842EEDB5; Sun, 18 Nov 2018 01:52:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 194842EEDB5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A7F641C3B21; Sun, 18 Nov 2018 01:52:58 -0500 (EST) Date: Sun, 18 Nov 2018 01:52:58 -0500 (EST) From: Paul Wouters To: Yoav Nir cc: Rafa Marin-Lopez , i2nsf@ietf.org, "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 06:53:18 -0000 On Wed, 14 Nov 2018, Yoav Nir wrote: > As discussed in the room, we need some reviewers for the sdn-ipsec-flow-protection draft ([1]) > > Thanks for these comments. Please see our response below. > > While any comments on any part of the document are welcome, I would like people to concentrate on the following issues: > * The YANG model in Appendix A > + Some of the crypto seems obsolete (example: DES). We would get into trouble in SecDir review.  OTOH ChaCha20-Poly1305 is missing.. Based on the introduction and abstract of the draft, this document does two things: 1) Specify a yang model for use with SDWAN + IKE + IPsec 2) Define the desired modes and algorithms to use with 1) It does not try to map the entire IKE/IPsec IANA registry into a yang model. Let me know if this is incorrect, because I use this as an assumption for the remainder of the review. > The TLS working group went quite far with TLS 1.3.  Only 2 ciphers remain: AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That’s it.  Specifically, they’ve deprecated everything > that isn’t an AEAD. I think this can work for this SDWAN use case as well. While I don't think all systems are ready to support ChaCha20-Poly1305 for both IKE and ESP, I do believe all systems used for SDWAN should be able to do AES-GCM with 16-byte ICV for IKE and ESP. Although some IKE clients do not yet support AES-GCM for IKE (even while they support it for ESP) > The IPsecME working group hasn’t gone that far yet.  But in practice pretty much nothing is used except 3DES, AES-CBC, and AES-GCM.  Perhaps ChaCha20-Poly1305 is starting to see > some use by now. We have RFC 8221, especially sections 5 and 6.  I think (although it’s up to the working group) that we should be fine defining only the MUSTs and the SHOULDs in > those sections. Yes, with the exception of ENCR_NULL for encryption and AUTH_HMAC_SHA1_96 for integrity. (the latter is a MUST- only because of existing deployment, it is not recommended for new things) > That brings another question. What is our plan for future expansions?  Suppose there’s some hot, new algorithm that everyone is implementing. How do you update the YANG model in > the future when you add new values to the enumerations?  Is it up to the administrator to make sure that the controller and NSFs are all on the “same page”? I'm wondering about that too, since it is basically a snapshot of the IANA registry SHOULD/MUST entries which changes over time. General comments: I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I keep losing track of which case is which. Perhaps call them IKE Case and IKE-less Case ? Section 1: Typically, traditional IPsec VPN concentrators and, in general, entities (i.e. hosts or security gateways) supporting IKE/IPsec, must be configured directly by the administrator. This makes the IPsec security association (SA) management difficult and generates a lack of flexibility, specially if the number of security policies and SAs to handle is high. This is not entirely true. We have Opportunistic IPsec that automates this precisely for the same reasons. We also have packet triggers in combination with Traffic Selector narrowing to create multiple IPsec SA's on demand. I know this is all qualified by "typically" but I think this paragraph is not adding any real information. The idea is that we have an SDWAN situation with SDN controllers and nodes, and we want to automate the IKE/IPsec for that specific deployment use case. The analysis of the host-to-gateway (roadwarrior) scenario is TBD. Does this sentence mean this is to be done in this document or is it out of scope for this document (but it does allow it to be added later) ? Section 3: It requires information about the required authentication method (i.e. preshared keys), DH groups, modes and algorithms for IKE SA negotiation, etc. In the IKE world, we really try to not recommend preshared keys, because these keys mostly based on human readable low entropy content. If this document thinks raw RSA/ECDSA keys or X.509 certificates are also methods that will be implemented by SDN Controllers, please change the example of preshared keys to something else. Section 5.1: The diagram lists: | IKE | IPsec(SPD,PAD) | Shouldn't that be: | IKE(PAD) | IPsec(SPD, SAD) IKE is using the PAD information to tell IPsec to establish SPDs and SADs) ? Section 5.1.1: What does this mean: Moreover, an east-west interface is required to exchange IPsec-related information. Section 5.2: In this case, the NSF does not deploy IKEv2 and, therefore, the Security Controller has to perform the management of IPsec SAs by populating and monitoring the SPD and the SAD. I would write: In this case, the NSF does not deploy IKEv2 and, therefore, the Security Controller has to perform the IKE security functions and management of IPsec SAs by populating and managing the SPD and the SAD. I added "IKE security functions" to make sure some entity is responsible for those items that are normally done by IKE (IV generation, prevent counter resets for same key, etc). I changed monitoring to managing, because I don't understand how it would "monitor" the NSF or what it would monitor. I assume also if during monitoring it finds something that needs changing (eg vpn tunnel up or down) that it will do so, so I think managing is the better word. For this diagram, I would say IPsec(SPD, SAD) would need to also list the IKE security function it needs to use in an IKE-less scenario, which above I had called "management of IPsec SAs" Section 5.3: As mentioned before, a better title would be: IKE vs IKEless I would also start this section with: Case 1 is more secure, because all security features of IKE are used to manage the IPsec SAs. Section 5.3.1: For case 1, the rekeying process is carried out by IKEv2, following the configuration defined in the SPD. Technically this is the SPD and SAD, as the SPD would for example list the maximum number of packets allowed, but the SAD lists the number of packets that have happened. I am a bit confused by the rekey description. I guess it assumes that the Security Controller sending of information is blocking? Eg when it tells the node to install an inbound IPsec SA, it is blocked from doing anything else. If this is not the case, then the 3 step program should be clarified that it needs to also receive confirmations. And if this is a non-blocking process, who is responsible for "retransmits" of these confirmations ? The same applies to the blocking or time-wait between step 2 and 3. Also, I would say step 3 can be get rid of if the IPsec implementation can itself detect traffic on the new IPsec SA and it can delete the old IPsec SA itself without instruction from the Security Controller. Section 5.3.2: If one of the NSF restarts, it may lose part or all the IPsec state This "may" suggests a very interesting case. I doubt the NSF would store on non-volatile memory the IPsec symmetric keys for encryption, and the counter or ICV's used. If it could store that, the document needs some text about this in the Security Considerations because it will allow for easier theft of session material. Rather, I suspect this may really is not true, and all of these devices would lose state? In both cases, the Security Controller MUST be aware of the affected NSF I think this MUST is a little misleading. It is not desired behaviour but just an observation - it cannot not know its TCP session died ? Perhaps write: In both cases, the Security Controller is aware of the affected NSF A similar case for the next sentence MUST keyword: Moreover, the Security Controller MUST have a register about all the NSFs that have IPsec SAs with the affected NSF. so write: Moreover, the Security Controller has a register about all the NSFs that have IPsec SAs with the affected NSF. (It is TBD in the model). This remark seems to need to be resolved before publication ? In Case 2, if the Security Controller detects that a NSF has lost the IPsec SAs (e.g. it reboots) it will follow similar steps to rekey: the steps 1 and 2 remain equal but the step 3 will be slightly different. For example, if we assume that NSF B has lost its state, the Security Controller MUST only delete the old IPsec SAs from A in step 3. I don't understand why this paragraph about NSF state loss seems to talk about "step 3" which can only be referring to the "rekeying process" of the previous section. It should only mention that it should configure new IPsec SAs between the failed node and all the nodes the failed node talked to and only after those are estlibhsed, it can send a delete for the old IPsec SAs on the non-failed nodes. This prevents the non-failed nodes from leaking plaintext. Section 5.3.3: I'm confused how the Security Controller can know what NAT ports to convey to the NSF agent. Without IKE traffic, there is no port NAT mapping? So unless the Security Controller _is_ the NAT gateway, it would never know this information? So I am skeptical if the NAT case can ever work without IKE. I also do not know how the Security Controller could decide between UDP, TCP or TLS without information from an IKE negotiation. Section 6.1: Note that the use of start and end addresses, means that this can never work with IKEv1, that can only negotiate CIDR networks. Perhaps this should be explicitely stated somewhere just in case some developer thinks they can use IKEv1 for this? I dont understand the names in: next-layer-protocol* ipsec-next-layer-proto It talks about ip-address and not ipsec-next-layer-ip-address? Simiarly it talks about local-ports. So why not just call this proto or protocol ? Is selector-priority needed? Can the ts-number not be specified to be "lower numer is higher priority" ? Why do we have security-protocol? If you are considered about small footprints, clearly you would implement only ESP and use ESP-NULL if encryption is not needed. And simply not implement AH (which is already optional not mandatory to implement for IPsec). Also, this assumes IPCOMP, which has its own complexity, would also not be used. I think a case for AH would be very weak, while a case for IPCOMP could be made. I'd recommend only supporting ESP, at which point you would not need this parameter, or you could keep it for completeness sake even though it could only have one value "esp". This would also allow an updated ESP or some ESPlite to be used in the future if such a thing would be developed. If we only go with AEAD algorithms, then the whole ah-algorithms part can be removed too. And esp-algorithms could be changed to only contain esp-encryption (or could be renamed aead-algorithm) I see spd-mark but not spd-security-context (see my Labeled IPsec draft) I found the names in lifetimes confusing. "added" really means maxlife and "current" really means maxidle I think? So I think the names would be clearer as "time", "idle", "packets", "bytes". I think the time and idle units of uint64 could be narrowed down if the yang language allows some kind of timestamp type. I am missing an entry for TFC (confidentiality, padding) I also see no entry for IPCOMP algorithm. But I am fine with not allowing IPCOMP at all :) I am missing replay window parameters ? I don't know what statefulfragCheck is ? Section 6.2 See Section 6.1 comments. Why are the encap entries in 6.2 and not 6.1 ? What is the "state?" entry ? Why is rpcs: only here? I would not use minbits, maxbits. All modern ciphers, especially AEAD, are fixed key sizes. Make it a list of key sizes I seem to miss the AEAD IV values ? Possibly the truncation values ? Section 6.3: I only see PSK and RSA algorithms? No ECDSA via RFC 7427 Digital Signatures? (no PAKE, we have two IKE PAKE's although it looks like we want an CFRG new one) Should PSK be of type "string". Some people want to hex entry? Although those are often written as strings with a 0x prefix. I see some CRL entries, but no OCSP entries. Is it expected those URI's are stored within the certificates, and the received OCSP responses will never be communicated through this interface? I see no local and remote part, meaning that only symmetric authentication methods can be used. IKEv2 supports asymmetric authentication methods as well. Especially when using EAP and sometimes with AUTHHNULL, this method is very asymmetric. So I believe this entry needs to be split in a local/remote auth method. Section 6.4: type-autostartup issues... typedef type-autostartup { type enumeration { enum ALWAYSON { description " ";} enum INITIATE-ON-DEMAND {description " ";} enum RESPOND-ONLY {description " ";} } description "Different types of how IKEv2 starts the IPsec SAs"; With libreswan we have similar keywords, and run into some interesting issues. We found what is really needed is to know the current state and the connection desired state. for example, when using ondemand and the connection is up, it is important to know it is up because of ondemand. So that when you receive a Delete request, you can go back to ondemand state. If you dont keep this state then you cannot tell the difference between alwayson/ondemand if the connection is "up". Similarly, we had issues where connections has a definition like above, but the administrator performs an action. It is unclear if such an action is considered a temporary override or basically a runtime update of the configuration. So lets say we are in respondonly, and the administrator brings the connection up. Now the other end sends a delete. Do you assume you are in alwayson state or in ondemand state? And if you believe alwayson, be prepared for a war with the remote endpoint that keeps sending deletes because it wants to be down. Why is there nat-traversal and espencap. Why not just have espencap allow to have a value of 'none' ? IKEv2 allows more then one oaddr (eg multiple SOURCE NAT IPs) but the value is not a list? The terms phase1-* should be called ike-* or ike-sa-* as phase1/phase2 is IKEv1 terminalogy not used for IKEv2. Why is combined-enc-intr needed? These are stored with the encalg entries anyway. I see: +--rw local | +--rw (my-identifier-type)? +--rw remote | +--rw (my-identifier-type)? I think "my-identifier-type" should be "identifier-type". Talking about "my" for the remote peer is very confusing. my-identifier-type does not support the value ID_NONE from RFC 7619 Why is there no secion for ike-lifetime-{soft|hard} ? We also have FIPS requirements that IKE SA's cannot do more then X bytes for Y algorithm. And also bringing down idle IKE SA's etc. I think "added", "used", "bytes" "packets" should be called lifetime, idletime, maxbytes and maxpackets The timestamp values "added" and "used" could have a better type than uint64, eg unix epoch of unixtime or something? the term ike-stats was confusing me. I thought at first these were the global IKE statistics, like how many tunnels are up, how many errors received, but it turned out to be the state of a singe IKE SA. So perhaps ike-sa-state is a better term? IKE state I expect things like SPIi and SPIr as listed here. I am not sure why there are three nat-* bools instead of one value representing the nat-state? Possibly because we use a number of bits to indicate which of the NAT properties are set, and you don't do this kind of bit mapping in yang? I dont see an entry for "latest IKE SA". We have that in libreswan. You can have multiple IKE SA's when rekeying, and the older one is just lingering to die. Any operations such as informational requests, dpd/liveness probes should only be done with the "latest IKE SA". However, this is kind of a state on the IKE node, so I am not sure if this belongs in the yang model or not. I see a total SA's and halfopen SA's but I don't see anything related to anti-DDOS cookies. Eg the number of half open SA's before enabling cookies. Perhaps add half-open-cookies-treshhold ? Section 7.1 Yes I do like this diagram style with less -+-+-+-+ better. Please use it everywhere in the document :) In case 2, flow-based security policies defined by the administrator are also translated into IPsec SPD entries I don't understand the use of "also" in this sentence. Since these are not translated into IKEv2 policies like case 1. (also reminder to use "IKE case" and "IKEless case" instead of "case 1" and "case 2") Question: since IPsec SA parameters installed in the kernel have lifetime values, what is installed here? Is it installed without any limits? If no limits what happens at max counter for AEAD? If there are limits, and the kernel generates ACQUIRES for userland, and no IKe is listening, what happens? How are things signaled? Does the ikeless node listen for netlink/pf_key messages to relay to the Security Controller? Section 7.2: Where does the terminology East/West come from? (and earlier South) ? 3. The Security Controller A realizes that protection is required between the NSF1 and NSF2, but the NSF2 is under the control of another Security Controller (Security Controller B), so it starts negotiations with the other controller to agree on the IPsec SPD policies and IKEv2 credentials for their respective NSFs. NOTE: This may require extensions in the East/West interface. The negotiation protocol for this is not specified. I would think IKE can be used here? Is there a reason why this is not being defined here as using IKEv2? Is there another protocol ? Especially since in the next case (with figure 6) it does state this protocol can be IKEv2 and states for both cases an IKE implementation was used. Section 8: Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required note to the RFC Editor to remove the entire section before publication as RFC. section 9.1: In case 1, add a note to use only strong PSKs, with a minimal length and strength. Section 9.2: when ESP is used Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please remove this comment as ESP would always be used. includes the keys for integrity and encryption If we only allow AEAD's, maybe rewrite or leave tis out. Appendix A: Why is it "eipsec" and not "ipsec" ? Why is the organization not the IETF? Is this commonly done for yang models? encryption-algorithm-t - I think this should only list the MUST/SOULD items, so AES_GCM (1 flavour), AES_CCM (1 flavour) CHACHAPOLY1305 and NULL description "Encryption algorithms -> RFC_5996"; RFC 5996 is an obsolete reference. It should either refer to RFC 7296, or it should simply refer to the IANA registry involved. integrity-algorithm-t: If the above is agreed, this enumeration should only contain "none" and the entries from aes-cmac-96 and up. That is, not contain des,md5,sha1 and aes_xcbc. Same obsolete reference is used here in the description. type-autostartup: Maybe instead of RESPOND-ONLY, a better word is "STANDBY"? That way, the node could decide itself to bring a connection up without _requiring_ a remote signal, and could be triggered locally as as well as remotely to come up. description "Different types of how IKEv2 starts the IPsec SAs"; I would say "different policies of when to start an IKEv2 based IPsec SA". Does it need clarification this value is ignored or unused for the "case 2" scenario? auth-protocol-type: This should only contain IKEv2. The enum should remain in case we get IKEv2.1 or IKEv3 in the future. description "Peer authentication protocols"; I would say "IKE authentication protocol version", unless you want to keep the option open to have a non-IKE protocol. But I think that would run into many more issues of having parameters that are not defined for IKE? ipsec-mode: It should only contain Tunnel and Transport Mode. It would be nice to see some text that forbids using Transport Mode when NAT is requested, just to avoid a lot of problems and disappointments. L2TP/IPsec still has major scars due to its use of Transport Mode with NAT. esp-encap: as stated before, we are missing the port entry. I can also image that multiple encaps could be allowed, such as TCP-443 and TLS-443. Also note that the RFC for ESP over TCP recommends to continiously check if UDP encapsulation has become available, since it is so much prefered over TCP. But that only makes sense when the remote is a roaming client, and makes less sense if the network consists of data centers. ipsec-protocol: I think this should only contain esp. See earlier comments. Notably, if supporting ipcomp here, the yang model must be clear that it could need an ipcomp + esp IPsec SA for a single 'connection'. Even if we only leave esp as a valid option, keep this enum in case we come up with a new esp version of some esp-lite version. lifetime-action only has "terminate" and "rekey". For libreswan we use "clear", "hold" and "restart". The difference between clear and hold is what kernel policy to install for cleartext packets. For roadwarrionrs coming in, you want clear to leave no trace. for a site-to-site VPN you generally want "hold" to ensure you drop all packets until a new tunnel is established (possible ondemand, so this is different from restart) ipsec-traffic-direction: Traditionally, freeswan ony used inbound/outbound and not forward. Unfortunately, KAME and Linux/XFRM kept forward there. But I see no use case for it in these deployments. We have nothing specified in about ipsec-sa's for the forward (it's basically implied "completely open") But I understand it might be useful to just specify this because it is needed. But perhaps more language is then needed to clarify this? ipsec-spd-operation: The value BYPASS probably means "let go in the clear" but I don't find the name very obvious. The operation modes BYPASS and DISCARD cannot be configured with the current yang parameters for IKE? How would this be configured, eg to place a DISCARD for 192.1.2.0/24 ? In libreswan we can configure a connection with type=transport|tunnel|drop|reject but that meshes up the IPsec Mode with the SPD Operation. It is also a bit odd to configure "IKE" for a "DISCARD" since it really does not define anything in IKE - it bypasses IKE to put in an IPsec policy (SPD). But if the yang model used the ipsec parts to do this, it could be mixing IKE + manual IPsec policies, which could really confuse the IKE daemon. I am not sure what the best fix for this is. Note REJECT which is DISCARD+ICMP message is not defined here. Should it? I don't think Linux/XFRM/netlink supports this. ipsec-next-layer-proto: See earlier note. I think this is a really bad name. ipsec-spd-nam: This is the first time I have seen an SPD as having a name. normally these just have numbers. Or they have a number that is the link between SPD and SAD (with linux, that is called reqid=) So maybe add an enum id_number so implementors could map this onto the linux implementation ? auth-method-type: See earlier comment about asymmetric authentication. This should only contain pre-shared, null, eap, rsa, rfc7427(digital signatures). That is I think dss-signature can be removed. I also wonder if this entry needs to have a better difference for the source of the private/public keypair, eg raw RSA versus RSA certificate based authentication. I guess this is now implied by not having a certificate entry? Also rename description "Peer authentication method" to "IKE authentication method" (it should mention this is IKE, but also in case of asymmetric use, this is not neccessarilly for the peer but how we authenticate _to_ the peer) sa-state: I am not sure why this is needed? Unless someone would want to manually place larval/acquire states in the kernel without IKE, but then who is going to listen to these ACQUIRE messages? A non-IKE daemon? See earlier discussion on this topic. If you do want to get netlink/pf_key messages for max-counter, max-bytes etc without IKE, then this would be required. Otherwise this should be removed. lifetime: See earlier comments. grouping auth-method-grouping: See earlier comments about asymmetric authentication and raw vs cert based signatures. Note based on above entries, this is missing a dss-signature section. So if you agree with earlier comment to remove dss-signature, then it not appearing here is fine. grouping identity-grouping: See earlier comments on ID_NULL / AUTH_NULL support grouping port-range: I don't see anywhere that protocol and ports together are "overloaded" for things like ICMP message types. Should language be added for that? SAD and SPD grouping : See earlier note about Security Labels. It would need to be added here. Linux/XFRM already supports these. I see container-ah and container-esp, but what about container-ipcomp? Again, if we remove IPCOMP as I'd like, then we are fine here. but if not, then something needs to be added here. If AH is removed as I'd recommended, it needs to be removed here. container sad-lifetime-soft { description "SAD lifetime hard state data"; that "hard" should be "soft". I am confused that "hard" and "soft" have an action that can be similar. soft could have an action to just notify userland via XFRM/PF_key, but "hard" can only have an option "terminate" ? container encap: Now I see the sport / dport, but I'm still confused how this is populated from the higher level Security Controller communication (if not IKE). Note also the Security Controllers cannot know the port numbers without sending any traffic so the NAT gateway crates a mapping. list traffic-selector-list: Can a traffic selector have a direction of fwd ? Not in the IKE protocol. leaf mode { type ipsec-mode; description "transport/tunnel"; } This "description" does not match all the available options defined before. container ah-algorithms: See AH comments before. Also see IPCOMP comments before. description "Configure ESP encryption" Maybe say "Configure ESP/AEAD encryption" spd-mark: Note that the IKE case cannot negotiate this spd-mark value. Is such a capability needed? It is similar to negotiating a Security Context. container spd-lifetime-*: See earlier comments on hard/soft and acceptable actions grouping isakmp-proposal: I would call this ike-proposal as isakmp is kind of an IKEv1 term. See also phase1-* value suggestions earlier to make those ike-* or ike-sa-* values. This group is also missing pfs= which for IKEv2 only starts to matter when rekeying and whether or not to do a new DH. grouping phase2-info: Call this ipsec-info: or ipsec-sa-info: leaf-list pfs_group { type uint32; This should really be an enum and not a uint32. typedef sadb-msg-type: where/when are these used? That is, I understand the IKE <-> IPsec API uses this, but when does this ever need to go over the Security Controller's communication ? typedef sadb-msg-satype: same here container algorithm-supported: See earlier comments about all moderm algorithms not having a min/max but only having a limited set, for current ones this is only 128/192/256 Note the version of IKE within the ietf-ipsec namespace only has IKEv2. I agree with that now but earlier in the document it has IKEv1 support/entries. So this needs to be made consistent here. container ike-stats: does not contain encaps entry to show if it is using UDP, TCP or TLS and on which port. list child-sas: does not contain some "state" that can be negotiated as part of an IKE session. For example, if narrowing was used, it could be that the current SPD is more narrow then the "connection" defined SPD. There seems to be no way to store this. Thus narrowing is not possible. If narrowing is not in scope here, it should probably be made more explicit. Otherwise, it needs to be better integrated. container number-ike-sas: See earlier note about missing COOKIES parameter here. SPD related question: Is there support for multiple TSi/TSr generating a list of spd's in a single Child SA? If so, a Child SA can have multiple SPDs. Otherwise, it cannot. I dont think the model is very clear on this aspect. (I speak from experience, libreswan as an implementation is also not very clearly specified here, and we have one known interop issue with openbsd's iked because of this) // Those RPCs are needed by a Security Controller in case 2 */ Please think about XFRM/netlink and/or ACQUIRE messages that are needed if there is no IKE daemon. eg when max-counter is reached or when a hard limit action is performed by the kernel. I am missing an "SPI already in use" error, in the case it is attempted to install an SPD that already exists and thus would conflict. NITS: Introduction: What does this mean: "with a reduced intervention of the network administrator." Section 1: IPsec architecture -> The IPsec architecture Section 5.1: besides the IPsec support. Change "besides" to "along with" ? With these entries, the IKEv2 implementation can operate to establish the IPsec SAs. Change to: With this information from the SDN Controller, the NSF can use its IKEv2 implementation to establish the IPsec SAs. Personally I don't like this Christmas like boxes: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPsec Management/Orchestration Application | Client or | I2NSF Client | App Gateway +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and prefer: +-------------------------------------------+ |IPsec Management/Orchestration Application | Client or | I2NSF Client | App Gateway +-------------------------------------------+ Section 5.3: Moreover hosts can install easily an IKE implementation. As downside, the NSF needs more resources to hold IKEv2. Moreover, the IKEv2 implementation needs to implement an interface so that the I2NSF Agent can interact with them. Change to: Usually, hosts can easily install an IKE implementation, although such an NSF needs more resources to run and it would need an interface for the communication between IKEv2 and the I2NSF Agent. Section 5.3.2: It has also to send new Change to: It also has to send new Nevertheless other more optimized options can be considered (e.g. making iKEv2 configuration permanent between reboots). Change to: A more consistent and secure deployment would store the IKEv2 configuration on non-volatile storage, so all information is available after a crash or reboot. IPsec SA information MUST NOT be stored on non-volatile storage to prevent incorrect and insecure re-use of symmetric key material. Section 7.1: Besides, fresh SAD entries will be also generated by the Security Controller Change to: Fresh SAD entries will also be generated by the Security Controller What are "IaaS services" ? section 9.2: SHOULD NEVER stores the keys change to: SHOULD NEVER store the keys it may access to these values. change to: it may have access to these values. observe the traffic change to: observe traffic In any case, some escenarios change to: Some scenarios Moreover, some scenarios change to: Scenarios Appendix: I see a few "->" manglings. From nobody Sun Nov 18 03:14:58 2018 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 C79BA12F1AC; Sun, 18 Nov 2018 03:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_XPILL=2.799, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 9YdsfoYB42Dy; Sun, 18 Nov 2018 03:14:48 -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 73550127148; Sun, 18 Nov 2018 03:14:47 -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 wAIBEewM002684 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Nov 2018 13:14:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAIBEepX017981; Sun, 18 Nov 2018 13:14:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23537.18848.15817.35029@fireball.acr.fi> Date: Sun, 18 Nov 2018 13:14:40 +0200 From: Tero Kivinen To: Paul Wouters Cc: "Waltermire\, David A. \(Fed\)" , "ipsec\@ietf.org" , "ipsecme-chairs\@ietf.org" , "draft-ietf-ipsecme-split-dns\@ietf.org" , Benjamin Kaduk , The IESG In-Reply-To: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 33 min Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 11:14:50 -0000 Paul Wouters writes: > On Fri, 16 Nov 2018, Waltermire, David A. (Fed) wrote: > > > One comment on your COMMENT wearing chair and shepherd hats: > > > >> We have to use DNS presentation format for the DS records and not wire > >> format? > > > > The group was "split" on this question. We did a hum, with most > > responding in the room that they either did not care or had a > > slight preference for presentation format. This is why it is this > > way. > > Note that we did not use humming as a vote. The humming gave an idea of > the room that the disadvantage of IKE software needing to understand and > convert wire to/from presentation format only to prevent "string > overflow errors" was not worth the trouble of forcing a wire format, > especially since IKE just relays this information to another > application, and this API almost certainly uses presentation format > (for example, unbound-control) Actually the text in section 2.2 is confusing. It is claiming that This attribute lists the corresponding internal DNSSEC trust anchor in the DNS presentation format of a DS record as specified in [RFC4034]. The format we use for DS records is not presentation format, nor is it wire format. In section 3.2 we see that we are using Wire format for DNSKEY Key Tag, DNSKEY Alg and Digest Type, but presentation format for Digest Data. I.e., we do split the DNSKEY Key Tag, DNSKEY Alg, and Digest type fields out from the presentation format and encode them as 16- and 8-bit integers in wire format, but then for the Digest Data, which in wire format would be just binary blob, we use Presentation format of the DS, i.e., hexadecimal with all kind of parenthesis, comments, escaping mechanisms and newlines. I myself would have been much more happy with wire format also for Digest Data, but authors wanted to allow things like: INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656 ; comments D14D9246558 ; in file 77628FFD6A98D7A847E ) ; more") Which is then encoded as: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type 0x19 | Length 0x48 | +-+-----------------------------+---------------+---------------+ | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| +-------------------------------+---------------+---------------+ | 0x28 "(" 0x20 " " 0x35 "5" 0x30 "0" | | 0x36 "6" 0x41 "A" 0x44 "D" 0x33 "3" | | 0x41 "A" 0x36 "6" 0x35 "5" 0x36 "6" | | 0x20 " " 0x20 " " 0x2B ";" 0x20 " " | | 0x63 "c" 0x6f "o" 0x6d "m" 0x6d "m" | | 0x65 "e" 0x6e "n" 0x74 "t" 0x73 "s" | | 0x0a "\n" 0x09 "\t" 0x09 "\t" 0x44 "D" | | 0x31 "1" 0x34 "4" 0x44 "D" 0x39 "9" | | ... | +---------------------------------------------------------------+ and so on, instead of: INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E) with DS wire format encoding for Digest Data would result following attribute: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type 0x19 | Length 0x1c | +-+-----------------------------+---------------+---------------+ | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| +-------------------------------+---------------+---------------+ | 0x50 0x6a 0xd3 0xa6 | | 0x56 0xd1 0x4d 0x92 | | 0x46 0x55 0x87 0x76 | | 0x28 0xff 0xd6 0xa9 | | 0x8d 0x7a 0x84 0x7e | +---------------------------------------------------------------+ -- kivinen@iki.fi From nobody Sun Nov 18 20:50:41 2018 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 94D991277D2; Sun, 18 Nov 2018 20:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UbopOnQMTVPN; Sun, 18 Nov 2018 20:50:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C096127332; Sun, 18 Nov 2018 20:50:32 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA10D3082A42; Mon, 19 Nov 2018 04:50:31 +0000 (UTC) Received: from thinkpad.nohats.ca (ovpn-204-33.brq.redhat.com [10.40.204.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id BD8B618EFA; Mon, 19 Nov 2018 04:50:27 +0000 (UTC) To: Alexey Melnikov , The IESG Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org References: <154247645671.15969.2304550137908278124.idtracker@ietfa.amsl.com> From: Paul Wouters Message-ID: <559e3d1d-ad44-ccd5-e3ed-2f2ac88facb9@redhat.com> Date: Mon, 19 Nov 2018 11:50:24 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154247645671.15969.2304550137908278124.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Mon, 19 Nov 2018 04:50:31 +0000 (UTC) Archived-At: Subject: Re: [IPsec] Alexey Melnikov's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 04:50:33 -0000 On 2018-11-18 12:40 a.m., Alexey Melnikov wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a well written document, so thank you for that. > I've noticed that Benjamin already found typos that I found and raised one of > the same questions, but I think this is important enough to be addressed before > I recommend approval of this document. Specifically: > > In Section 3.1: > > o Domain Name (0 or more octets) - A Fully Qualified Domain Name > used for Split DNS rules, such as "example.com", in DNS > presentation format and optionally using IDNA [RFC5890] for > Internationalized Domain Names. > > Do you mean A-label or U-label form here? I thought it was obvious that we meant A-label. Why else refer to IDN if you would just put in U-label, but I'll add the A-label term. Paul From nobody Sun Nov 18 20:59:37 2018 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 1CAD612D4EF; Sun, 18 Nov 2018 20:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_XPILL=2.799, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable 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 9bLMHLsQ-HoQ; Sun, 18 Nov 2018 20:59:22 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CC31277D2; Sun, 18 Nov 2018 20:59:22 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C1833082A42; Mon, 19 Nov 2018 04:59:22 +0000 (UTC) Received: from thinkpad.nohats.ca (ovpn-204-33.brq.redhat.com [10.40.204.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6448C103BAB3; Mon, 19 Nov 2018 04:59:12 +0000 (UTC) To: Tero Kivinen , Paul Wouters Cc: "Waltermire, David A. (Fed)" , "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "draft-ietf-ipsecme-split-dns@ietf.org" , Benjamin Kaduk , The IESG References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> From: Paul Wouters Message-ID: Date: Mon, 19 Nov 2018 11:59:08 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <23537.18848.15817.35029@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Mon, 19 Nov 2018 04:59:22 +0000 (UTC) Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 04:59:25 -0000 On 2018-11-18 6:14 p.m., Tero Kivinen wrote: > Actually the text in section 2.2 is confusing. It is claiming that > This attribute lists the corresponding internal DNSSEC > trust anchor in the DNS presentation format of a DS record as > specified in [RFC4034]. > > The format we use for DS records is not presentation format, nor is it > wire format. That's correct. We used some strange compromise text :( > In section 3.2 we see that we are using Wire format for DNSKEY Key > Tag, DNSKEY Alg and Digest Type, but presentation format for Digest > Data. > > I.e., we do split the DNSKEY Key Tag, DNSKEY Alg, and Digest type > fields out from the presentation format and encode them as 16- and > 8-bit integers in wire format, but then for the Digest Data, which in > wire format would be just binary blob, we use Presentation format of > the DS, i.e., hexadecimal with all kind of parenthesis, comments, > escaping mechanisms and newlines. > > I myself would have been much more happy with wire format also for > Digest Data, but authors wanted to allow things like: The authors would have been happy with full presentation format for both :) You were the one that raised an issue that strings would be passed carelessly and could be abused by peer's to try and get a shell :P > > INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656 ; comments > D14D9246558 ; in file > 77628FFD6A98D7A847E ) ; more") I don't remember that I wanted to have comments. If I did, I certainly don't care now and I would be happy to move everything back to DNS presentation format. I would not want to use wireformat anywhere, because as I argued in the past, the IKE daemon is just passing on this information and for it to need to convert its DNS configuration, which is guaranteed to be in DNS presentation format, it would need to copy some DNS conversion code or link against some DNS library to convert it to wire format. And a security check could simply reject all characters outside [A-Za-z0-9\-_\.]* On the other end, passing the DNS information from IKE daemon to the system is most likely happening over a DNS presentation API as well, as all API's supporting commandline configurations cannot take DNS wire format but take DNS presentation format. So I think we have two options: 1) Clarify the text that the DS RRtype data is not in either wire or presentation format. 2) Change the DS RRtype data to also be fully DNS presentation format. I have a preference for 2) but I guess the working group in the past reached consensus on 1) Paul > > Which is then encoded as: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-----------------------------+-------------------------------+ > |R| Attribute Type 0x19 | Length 0x48 | > +-+-----------------------------+---------------+---------------+ > | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| > +-------------------------------+---------------+---------------+ > | 0x28 "(" 0x20 " " 0x35 "5" 0x30 "0" | > | 0x36 "6" 0x41 "A" 0x44 "D" 0x33 "3" | > | 0x41 "A" 0x36 "6" 0x35 "5" 0x36 "6" | > | 0x20 " " 0x20 " " 0x2B ";" 0x20 " " | > | 0x63 "c" 0x6f "o" 0x6d "m" 0x6d "m" | > | 0x65 "e" 0x6e "n" 0x74 "t" 0x73 "s" | > | 0x0a "\n" 0x09 "\t" 0x09 "\t" 0x44 "D" | > | 0x31 "1" 0x34 "4" 0x44 "D" 0x39 "9" | > | ... | > +---------------------------------------------------------------+ > > and so on, instead of: > > INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E) > > with DS wire format encoding for Digest Data would result following > attribute: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-----------------------------+-------------------------------+ > |R| Attribute Type 0x19 | Length 0x1c | > +-+-----------------------------+---------------+---------------+ > | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| > +-------------------------------+---------------+---------------+ > | 0x50 0x6a 0xd3 0xa6 | > | 0x56 0xd1 0x4d 0x92 | > | 0x46 0x55 0x87 0x76 | > | 0x28 0xff 0xd6 0xa9 | > | 0x8d 0x7a 0x84 0x7e | > +---------------------------------------------------------------+ From nobody Mon Nov 19 04:44:49 2018 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 A204E12F1A5; Mon, 19 Nov 2018 04:44:40 -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, 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 HDf6i_u1EwdR; Mon, 19 Nov 2018 04:44:36 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [IPv6:2001:720:1710:601::44]) by ietfa.amsl.com (Postfix) with ESMTP id D5AD5129C6B; Mon, 19 Nov 2018 04:44:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 1C2B01FFED; Mon, 19 Nov 2018 13:44:31 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L8fp7uJPLWCU; Mon, 19 Nov 2018 13:44:31 +0100 (CET) Received: from [155.54.12.91] (unknown [155.54.12.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 933E42011E; Mon, 19 Nov 2018 13:44:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Rafa Marin Lopez In-Reply-To: Date: Mon, 19 Nov 2018 13:44:28 +0100 Cc: Rafa Marin Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> To: Paul Wouters X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 12:44:41 -0000 Hi Paul: First of all, thank you very much for this impressive review. We are = going to process all your comments as soon as possible by separating our = answers in different e-mails so that the discussion is easier to follow. In any case, we would like to answer first to your initial question and = Yoav's > El 18 nov 2018, a las 7:52, Paul Wouters escribi=C3=B3:= >=20 > On Wed, 14 Nov 2018, Yoav Nir wrote: >=20 >> As discussed in the room, we need some reviewers for the = sdn-ipsec-flow-protection draft ([1]) >> Thanks for these comments. Please see our response below. >> While any comments on any part of the document are welcome, I would = like people to concentrate on the following issues: >> * The YANG model in Appendix A >> + Some of the crypto seems obsolete (example: DES). We would get = into trouble in SecDir review. OTOH ChaCha20-Poly1305 is missing.. >=20 > Based on the introduction and abstract of the draft, this document = does two things: >=20 > 1) Specify a yang model for use with SDWAN + IKE + IPsec > 2) Define the desired modes and algorithms to use with 1) >=20 > It does not try to map the entire IKE/IPsec IANA registry into a yang = model. Let me know if this is incorrect, because I use > this as an assumption for the remainder of the review. We must say that our I-D specifies 1) but being SDWAN one of the = possible scenarios to operate so that the intent was to map the = IKE/IPsec IANA registry. In any case we can change that approach if the = WG consider is the right way to proceed. >=20 >> The TLS working group went quite far with TLS 1.3. Only 2 ciphers = remain: AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That=E2=80=99s = it. Specifically, they=E2=80=99ve deprecated everything >> that isn=E2=80=99t an AEAD. >=20 > I think this can work for this SDWAN use case as well. While I don't = think all systems > are ready to support ChaCha20-Poly1305 for both IKE and ESP, I do = believe all systems > used for SDWAN should be able to do AES-GCM with 16-byte ICV for IKE = and ESP. Although > some IKE clients do not yet support AES-GCM for IKE (even while they = support it for ESP) >=20 >> The IPsecME working group hasn=E2=80=99t gone that far yet. But in = practice pretty much nothing is used except 3DES, AES-CBC, and AES-GCM. = Perhaps ChaCha20-Poly1305 is starting to see >> some use by now. We have RFC 8221, especially sections 5 and 6. I = think (although it=E2=80=99s up to the working group) that we should be = fine defining only the MUSTs and the SHOULDs in >> those sections. >=20 > Yes, with the exception of ENCR_NULL for encryption and = AUTH_HMAC_SHA1_96 for integrity. (the latter is a MUST- only because of = existing > deployment, it is not recommended for new things) >=20 >> That brings another question. What is our plan for future expansions? = Suppose there=E2=80=99s some hot, new algorithm that everyone is = implementing. How do you update the YANG model in >> the future when you add new values to the enumerations? Is it up to = the administrator to make sure that the controller and NSFs are all on = the =E2=80=9Csame page=E2=80=9D? >=20 > I'm wondering about that too, since it is basically a snapshot of the > IANA registry SHOULD/MUST entries which changes over time. This is really a good question. Most probably one better way would be = import another yang model that we could use. In fact, there is an = related effort in https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02 that we could use. In any case, we will follow your advise here. >=20 >=20 >=20 > General comments: > I'd like to see "Case 1" and "Case 2" replaced with more descriptive = terms. I keep losing track of which case is which. > Perhaps call them IKE Case and IKE-less Case ? >=20 >=20 > Section 1: >=20 > Typically, traditional IPsec VPN concentrators and, in general, > entities (i.e. hosts or security gateways) supporting IKE/IPsec, = must > be configured directly by the administrator. This makes the IPsec > security association (SA) management difficult and generates a lack > of flexibility, specially if the number of security policies and SAs > to handle is high. >=20 > This is not entirely true. We have Opportunistic IPsec that automates > this precisely for the same reasons. We also have packet triggers in > combination with Traffic Selector narrowing to create multiple IPsec > SA's on demand. I know this is all qualified by "typically" but I = think > this paragraph is not adding any real information. The idea is that we > have an SDWAN situation with SDN controllers and nodes, and we want to > automate the IKE/IPsec for that specific deployment use case. >=20 >=20 > The analysis of the host-to-gateway (roadwarrior) scenario is TBD. >=20 > Does this sentence mean this is to be done in this document or is it = out > of scope for this document (but it does allow it to be added later) ? >=20 > Section 3: >=20 > It requires information about the > required authentication method (i.e. preshared keys), DH groups, > modes and algorithms for IKE SA negotiation, etc. >=20 > In the IKE world, we really try to not recommend preshared keys, = because > these keys mostly based on human readable low entropy content. If this > document thinks raw RSA/ECDSA keys or X.509 certificates are also = methods > that will be implemented by SDN Controllers, please change the example = of > preshared keys to something else. >=20 > Section 5.1: >=20 > The diagram lists: >=20 > | IKE | IPsec(SPD,PAD) | >=20 > Shouldn't that be: >=20 > | IKE(PAD) | IPsec(SPD, SAD) >=20 > IKE is using the PAD information to tell IPsec to establish SPDs and = SADs) ? >=20 >=20 > Section 5.1.1: >=20 > What does this mean: >=20 > Moreover, an east-west interface is required to exchange = IPsec-related information. >=20 > Section 5.2: >=20 > In this case, the NSF does not deploy IKEv2 and, therefore, the > Security Controller has to perform the management of IPsec SAs by > populating and monitoring the SPD and the SAD. >=20 > I would write: >=20 > In this case, the NSF does not deploy IKEv2 and, therefore, the > Security Controller has to perform the IKE security functions and = management > of IPsec SAs by populating and managing the SPD and the SAD. >=20 > I added "IKE security functions" to make sure some entity is = responsible > for those items that are normally done by IKE (IV generation, prevent = counter > resets for same key, etc). >=20 > I changed monitoring to managing, because I don't understand how it = would "monitor" > the NSF or what it would monitor. I assume also if during monitoring = it finds > something that needs changing (eg vpn tunnel up or down) that it will = do so, > so I think managing is the better word. >=20 > For this diagram, I would say IPsec(SPD, SAD) would need to also list = the IKE > security function it needs to use in an IKE-less scenario, which above = I had > called "management of IPsec SAs" >=20 > Section 5.3: >=20 > As mentioned before, a better title would be: IKE vs IKEless >=20 > I would also start this section with: >=20 > Case 1 is more secure, because all security features of IKE are used = to manage > the IPsec SAs. >=20 > Section 5.3.1: >=20 > For case 1, the rekeying process is carried out by IKEv2, following > the configuration defined in the SPD. >=20 > Technically this is the SPD and SAD, as the SPD would for example list = the > maximum number of packets allowed, but the SAD lists the number of = packets > that have happened. >=20 > I am a bit confused by the rekey description. I guess it assumes that = the > Security Controller sending of information is blocking? Eg when it = tells > the node to install an inbound IPsec SA, it is blocked from doing = anything > else. If this is not the case, then the 3 step program should be = clarified > that it needs to also receive confirmations. And if this is a = non-blocking > process, who is responsible for "retransmits" of these confirmations ? > The same applies to the blocking or time-wait between step 2 and 3. >=20 > Also, I would say step 3 can be get rid of if the IPsec implementation = can > itself detect traffic on the new IPsec SA and it can delete the old = IPsec > SA itself without instruction from the Security Controller. >=20 > Section 5.3.2: >=20 > If one of the NSF restarts, it may lose part or all the IPsec = state >=20 > This "may" suggests a very interesting case. I doubt the NSF would = store on > non-volatile memory the IPsec symmetric keys for encryption, and the = counter > or ICV's used. If it could store that, the document needs some text = about > this in the Security Considerations because it will allow for easier = theft > of session material. >=20 > Rather, I suspect this may really is not true, and all of these = devices would > lose state? >=20 > In both cases, the Security Controller MUST be aware of the = affected NSF >=20 > I think this MUST is a little misleading. It is not desired behaviour = but just > an observation - it cannot not know its TCP session died ? Perhaps = write: >=20 > In both cases, the Security Controller is aware of the affected = NSF >=20 > A similar case for the next sentence MUST keyword: >=20 > Moreover, the Security Controller MUST have a register about all = the > NSFs that have IPsec SAs with the affected NSF. >=20 > so write: >=20 > Moreover, the Security Controller has a register about all the > NSFs that have IPsec SAs with the affected NSF. >=20 >=20 > (It is TBD in the model). >=20 > This remark seems to need to be resolved before publication ? >=20 > In Case 2, if the Security Controller detects that a NSF has lost = the > IPsec SAs (e.g. it reboots) it will follow similar steps to rekey: > the steps 1 and 2 remain equal but the step 3 will be slightly > different. For example, if we assume that NSF B has lost its state, > the Security Controller MUST only delete the old IPsec SAs from A in > step 3. >=20 > I don't understand why this paragraph about NSF state loss seems to = talk > about "step 3" which can only be referring to the "rekeying process" = of > the previous section. It should only mention that it should configure = new > IPsec SAs between the failed node and all the nodes the failed node = talked > to and only after those are estlibhsed, it can send a delete for the = old > IPsec SAs on the non-failed nodes. This prevents the non-failed nodes = from > leaking plaintext. >=20 > Section 5.3.3: >=20 > I'm confused how the Security Controller can know what NAT ports to = convey to > the NSF agent. Without IKE traffic, there is no port NAT mapping? So = unless > the Security Controller _is_ the NAT gateway, it would never know this > information? So I am skeptical if the NAT case can ever work without = IKE. > I also do not know how the Security Controller could decide between = UDP, > TCP or TLS without information from an IKE negotiation. >=20 > Section 6.1: >=20 > Note that the use of start and end addresses, means that this can = never work > with IKEv1, that can only negotiate CIDR networks. Perhaps this should = be > explicitely stated somewhere just in case some developer thinks they = can > use IKEv1 for this? >=20 > I dont understand the names in: >=20 > next-layer-protocol* ipsec-next-layer-proto >=20 > It talks about ip-address and not ipsec-next-layer-ip-address? = Simiarly it > talks about local-ports. So why not just call this proto or protocol ? >=20 > Is selector-priority needed? Can the ts-number not be specified to be = "lower > numer is higher priority" ? >=20 >=20 > Why do we have security-protocol? If you are considered about small = footprints, > clearly you would implement only ESP and use ESP-NULL if encryption is = not > needed. And simply not implement AH (which is already optional not = mandatory > to implement for IPsec). Also, this assumes IPCOMP, which has its own = complexity, > would also not be used. I think a case for AH would be very weak, = while a case > for IPCOMP could be made. I'd recommend only supporting ESP, at which = point > you would not need this parameter, or you could keep it for = completeness > sake even though it could only have one value "esp". This would also = allow > an updated ESP or some ESPlite to be used in the future if such a = thing would > be developed. >=20 > If we only go with AEAD algorithms, then the whole ah-algorithms part = can be > removed too. And esp-algorithms could be changed to only contain = esp-encryption > (or could be renamed aead-algorithm) >=20 > I see spd-mark but not spd-security-context (see my Labeled IPsec = draft) >=20 > I found the names in lifetimes confusing. "added" really means maxlife = and > "current" really means maxidle I think? So I think the names would be > clearer as "time", "idle", "packets", "bytes". I think the time and = idle > units of uint64 could be narrowed down if the yang language allows = some > kind of timestamp type. >=20 > I am missing an entry for TFC (confidentiality, padding) > I also see no entry for IPCOMP algorithm. But I am fine with not = allowing > IPCOMP at all :) >=20 > I am missing replay window parameters ? >=20 > I don't know what statefulfragCheck is ? >=20 > Section 6.2 >=20 > See Section 6.1 comments. >=20 > Why are the encap entries in 6.2 and not 6.1 ? >=20 > What is the "state?" entry ? >=20 > Why is rpcs: only here? >=20 > I would not use minbits, maxbits. All modern ciphers, especially AEAD, = are fixed key sizes. Make it a list of key sizes >=20 > I seem to miss the AEAD IV values ? Possibly the truncation values ? >=20 > Section 6.3: >=20 > I only see PSK and RSA algorithms? No ECDSA via RFC 7427 Digital = Signatures? > (no PAKE, we have two IKE PAKE's although it looks like we want an = CFRG new one) >=20 > Should PSK be of type "string". Some people want to hex entry? = Although those are often written > as strings with a 0x prefix. >=20 > I see some CRL entries, but no OCSP entries. Is it expected those = URI's are stored within the certificates, > and the received OCSP responses will never be communicated through = this interface? >=20 > I see no local and remote part, meaning that only symmetric = authentication methods can be used. IKEv2 supports > asymmetric authentication methods as well. Especially when using EAP = and sometimes with AUTHHNULL, this method > is very asymmetric. So I believe this entry needs to be split in a = local/remote auth method. >=20 > Section 6.4: >=20 > type-autostartup issues... >=20 > typedef type-autostartup { > type enumeration { > enum ALWAYSON { description " ";} > enum INITIATE-ON-DEMAND {description " ";} > enum RESPOND-ONLY {description " ";} > } > description "Different types of how IKEv2 starts the IPsec SAs"; >=20 > With libreswan we have similar keywords, and run into some interesting = issues. We found what is really needed is to > know the current state and the connection desired state. for example, = when using ondemand and the connection is up, > it is important to know it is up because of ondemand. So that when you = receive a Delete request, you can go back > to ondemand state. If you dont keep this state then you cannot tell = the difference between alwayson/ondemand if > the connection is "up". Similarly, we had issues where connections has = a definition like above, but the administrator > performs an action. It is unclear if such an action is considered a = temporary override or basically a runtime update > of the configuration. So lets say we are in respondonly, and the = administrator brings the connection up. Now the other > end sends a delete. Do you assume you are in alwayson state or in = ondemand state? And if you believe alwayson, be > prepared for a war with the remote endpoint that keeps sending deletes = because it wants to be down. >=20 >=20 > Why is there nat-traversal and espencap. Why not just have espencap = allow to have a value of 'none' ? > IKEv2 allows more then one oaddr (eg multiple SOURCE NAT IPs) but the = value is not a list? >=20 > The terms phase1-* should be called ike-* or ike-sa-* as phase1/phase2 = is IKEv1 terminalogy not used for IKEv2. >=20 > Why is combined-enc-intr needed? These are stored with the encalg = entries anyway. >=20 > I see: >=20 > +--rw local > | +--rw (my-identifier-type)? >=20 > +--rw remote > | +--rw (my-identifier-type)? >=20 > I think "my-identifier-type" should be "identifier-type". Talking = about "my" for the remote peer is very confusing. >=20 > my-identifier-type does not support the value ID_NONE from RFC 7619 >=20 > Why is there no secion for ike-lifetime-{soft|hard} ? We also have = FIPS requirements that IKE SA's cannot do more > then X bytes for Y algorithm. And also bringing down idle IKE SA's = etc. >=20 > I think "added", "used", "bytes" "packets" should be called lifetime, = idletime, maxbytes and maxpackets >=20 > The timestamp values "added" and "used" could have a better type than = uint64, eg unix epoch of unixtime or something? >=20 > the term ike-stats was confusing me. I thought at first these were the = global IKE statistics, like how many tunnels > are up, how many errors received, but it turned out to be the state of = a singe IKE SA. So perhaps ike-sa-state is a > better term? IKE state I expect things like SPIi and SPIr as listed = here. >=20 > I am not sure why there are three nat-* bools instead of one value = representing the nat-state? Possibly because we > use a number of bits to indicate which of the NAT properties are set, = and you don't do this kind of bit mapping in > yang? >=20 > I dont see an entry for "latest IKE SA". We have that in libreswan. = You can have multiple IKE SA's when rekeying, > and the older one is just lingering to die. Any operations such as = informational requests, dpd/liveness probes > should only be done with the "latest IKE SA". However, this is kind = of a state on the IKE node, so I am not > sure if this belongs in the yang model or not. >=20 > I see a total SA's and halfopen SA's but I don't see anything related = to anti-DDOS cookies. Eg the number of half > open SA's before enabling cookies. Perhaps add = half-open-cookies-treshhold ? >=20 > Section 7.1 >=20 > Yes I do like this diagram style with less -+-+-+-+ better. Please use = it everywhere in the document :) >=20 > In case 2, flow-based security policies defined by the = administrator are also translated into IPsec SPD entries >=20 > I don't understand the use of "also" in this sentence. Since these are = not translated into IKEv2 policies like case 1. > (also reminder to use "IKE case" and "IKEless case" instead of "case = 1" and "case 2") >=20 >=20 > Question: since IPsec SA parameters installed in the kernel have = lifetime values, what is installed here? Is it installed > without any limits? If no limits what happens at max counter for AEAD? = If there are limits, and the kernel generates > ACQUIRES for userland, and no IKe is listening, what happens? How are = things signaled? Does the ikeless node listen > for netlink/pf_key messages to relay to the Security Controller? >=20 > Section 7.2: >=20 > Where does the terminology East/West come from? (and earlier South) ? >=20 > 3. The Security Controller A realizes that protection is required > between the NSF1 and NSF2, but the NSF2 is under the control of > another Security Controller (Security Controller B), so it = starts > negotiations with the other controller to agree on the IPsec SPD > policies and IKEv2 credentials for their respective NSFs. NOTE: > This may require extensions in the East/West interface. >=20 > The negotiation protocol for this is not specified. I would think IKE = can be used here? Is there a reason why this is > not being defined here as using IKEv2? Is there another protocol ? = Especially since in the next case (with figure 6) > it does state this protocol can be IKEv2 and states for both cases an = IKE implementation was used. >=20 >=20 > Section 8: >=20 > Is this section supposed to be an "Implementation Details" Section as = per RFC 7942? If so, it is missing the required > note to the RFC Editor to remove the entire section before publication = as RFC. >=20 > section 9.1: >=20 > In case 1, add a note to use only strong PSKs, with a minimal length = and strength. >=20 > Section 9.2: >=20 > when ESP is used >=20 > Hoping my advise is taken to only use ESP and not AH, and to use = ESP-null in the case of encryption being unwanted, please > remove this comment as ESP would always be used. >=20 > includes the keys for integrity and encryption >=20 > If we only allow AEAD's, maybe rewrite or leave tis out. >=20 >=20 > Appendix A: >=20 > Why is it "eipsec" and not "ipsec" ? >=20 > Why is the organization not the IETF? Is this commonly done for yang = models? >=20 > encryption-algorithm-t - I think this should only list the MUST/SOULD = items, so AES_GCM (1 flavour), AES_CCM (1 flavour) CHACHAPOLY1305 and = NULL >=20 > description "Encryption algorithms -> RFC_5996"; >=20 > RFC 5996 is an obsolete reference. It should either refer to RFC 7296, = or it should simply refer to the IANA registry involved. >=20 > integrity-algorithm-t: If the above is agreed, this enumeration should = only contain "none" and the entries from aes-cmac-96 and up. That is, > not contain des,md5,sha1 and aes_xcbc. Same obsolete reference is = used here in the description. >=20 > type-autostartup: Maybe instead of RESPOND-ONLY, a better word is = "STANDBY"? That way, the node could decide itself to bring a connection = up > without _requiring_ a remote signal, and could be triggered locally as = as well as remotely to come up. >=20 > description "Different types of how IKEv2 starts the IPsec SAs"; >=20 > I would say "different policies of when to start an IKEv2 based IPsec = SA". Does it need clarification this value is ignored or unused for the > "case 2" scenario? >=20 > auth-protocol-type: This should only contain IKEv2. The enum should = remain in case we get IKEv2.1 or IKEv3 in the future. >=20 > description "Peer authentication protocols"; >=20 > I would say "IKE authentication protocol version", unless you want to = keep the option open to have a non-IKE protocol. But I think that would > run into many more issues of having parameters that are not defined = for IKE? >=20 > ipsec-mode: It should only contain Tunnel and Transport Mode. It would = be nice to see some text that forbids using Transport Mode when NAT is > requested, just to avoid a lot of problems and disappointments. = L2TP/IPsec still has major scars due to its use of Transport Mode with = NAT. >=20 > esp-encap: as stated before, we are missing the port entry. I can also = image that multiple encaps could be allowed, such as TCP-443 and = TLS-443. > Also note that the RFC for ESP over TCP recommends to continiously = check if UDP encapsulation has become available, since it is so much = prefered > over TCP. But that only makes sense when the remote is a roaming = client, and makes less sense if the network consists of data centers. >=20 > ipsec-protocol: I think this should only contain esp. See earlier = comments. Notably, if supporting ipcomp here, the yang model must be = clear > that it could need an ipcomp + esp IPsec SA for a single 'connection'. = Even if we only leave esp as a valid option, keep this enum in case > we come up with a new esp version of some esp-lite version. >=20 > lifetime-action only has "terminate" and "rekey". For libreswan we use = "clear", "hold" and "restart". The difference > between clear and hold is what kernel policy to install for cleartext = packets. For roadwarrionrs coming in, you > want clear to leave no trace. for a site-to-site VPN you generally = want "hold" to ensure you drop all packets until > a new tunnel is established (possible ondemand, so this is different = from restart) >=20 > ipsec-traffic-direction: >=20 > Traditionally, freeswan ony used inbound/outbound and not forward. = Unfortunately, KAME and Linux/XFRM kept forward there. But I see no use > case for it in these deployments. We have nothing specified in about = ipsec-sa's for the forward (it's basically implied "completely open") > But I understand it might be useful to just specify this because it is = needed. But perhaps more language is then needed to clarify this? >=20 > ipsec-spd-operation: >=20 > The value BYPASS probably means "let go in the clear" but I don't find = the name very obvious. > The operation modes BYPASS and DISCARD cannot be configured with the = current yang parameters > for IKE? How would this be configured, eg to place a DISCARD for = 192.1.2.0/24 ? In libreswan > we can configure a connection with type=3Dtransport|tunnel|drop|reject = but that meshes up the > IPsec Mode with the SPD Operation. It is also a bit odd to configure = "IKE" for a "DISCARD" > since it really does not define anything in IKE - it bypasses IKE to = put in an IPsec policy > (SPD). But if the yang model used the ipsec parts to do this, it could = be mixing IKE + manual > IPsec policies, which could really confuse the IKE daemon. I am not = sure what the best fix for > this is. Note REJECT which is DISCARD+ICMP message is not defined = here. Should it? I don't > think Linux/XFRM/netlink supports this. >=20 > ipsec-next-layer-proto: >=20 > See earlier note. I think this is a really bad name. >=20 > ipsec-spd-nam: >=20 > This is the first time I have seen an SPD as having a name. normally = these just have numbers. Or they > have a number that is the link between SPD and SAD (with linux, that = is called reqid=3D) > So maybe add an enum id_number so implementors could map this onto the = linux implementation ? >=20 > auth-method-type: >=20 > See earlier comment about asymmetric authentication. >=20 > This should only contain pre-shared, null, eap, rsa, rfc7427(digital = signatures). That is I think dss-signature can be removed. > I also wonder if this entry needs to have a better difference for the = source of the private/public keypair, eg raw RSA versus > RSA certificate based authentication. I guess this is now implied by = not having a certificate entry? >=20 > Also rename description "Peer authentication method" to "IKE = authentication method" (it should mention this is IKE, but also > in case of asymmetric use, this is not neccessarilly for the peer but = how we authenticate _to_ the peer) >=20 > sa-state: I am not sure why this is needed? Unless someone would want = to manually place larval/acquire states in the kernel > without IKE, but then who is going to listen to these ACQUIRE = messages? A non-IKE daemon? See earlier discussion on this topic. > If you do want to get netlink/pf_key messages for max-counter, = max-bytes etc without IKE, then this would be required. Otherwise > this should be removed. >=20 > lifetime: See earlier comments. >=20 > grouping auth-method-grouping: See earlier comments about asymmetric = authentication and raw vs cert based signatures. Note based > on above entries, this is missing a dss-signature section. So if you = agree with earlier comment to remove dss-signature, then > it not appearing here is fine. >=20 > grouping identity-grouping: See earlier comments on ID_NULL / = AUTH_NULL support >=20 > grouping port-range: I don't see anywhere that protocol and ports = together are "overloaded" for things like ICMP message types. > Should language be added for that? >=20 > SAD and SPD grouping : See earlier note about Security Labels. It = would need to be added here. Linux/XFRM already supports these. >=20 > I see container-ah and container-esp, but what about container-ipcomp? = Again, if we remove IPCOMP as I'd like, then we are fine > here. but if not, then something needs to be added here. If AH is = removed as I'd recommended, it needs to be removed here. >=20 > container sad-lifetime-soft { > description "SAD lifetime hard state data"; >=20 > that "hard" should be "soft". >=20 > I am confused that "hard" and "soft" have an action that can be = similar. soft could have an action to just notify userland via > XFRM/PF_key, but "hard" can only have an option "terminate" ? >=20 > container encap: Now I see the sport / dport, but I'm still confused = how this is populated from the higher level Security Controller > communication (if not IKE). Note also the Security Controllers cannot = know the port numbers without sending any traffic so the > NAT gateway crates a mapping. >=20 > list traffic-selector-list: Can a traffic selector have a direction of = fwd ? Not in the IKE protocol. >=20 > leaf mode { type ipsec-mode; description = "transport/tunnel"; } >=20 > This "description" does not match all the available options defined = before. >=20 > container ah-algorithms: See AH comments before. Also see IPCOMP = comments before. >=20 > description "Configure ESP encryption" >=20 > Maybe say "Configure ESP/AEAD encryption" >=20 > spd-mark: >=20 > Note that the IKE case cannot negotiate this spd-mark value. Is such a = capability needed? It is similar to negotiating a Security Context. >=20 >=20 > container spd-lifetime-*: See earlier comments on hard/soft and = acceptable actions >=20 > grouping isakmp-proposal: I would call this ike-proposal as isakmp is = kind of an IKEv1 term. See also phase1-* value suggestions earlier to > make those ike-* or ike-sa-* values. This group is also missing pfs=3D = which for IKEv2 only starts to matter when rekeying and whether or not > to do a new DH. >=20 > grouping phase2-info: Call this ipsec-info: or ipsec-sa-info: >=20 > leaf-list pfs_group { type uint32; >=20 > This should really be an enum and not a uint32. >=20 > typedef sadb-msg-type: where/when are these used? That is, I = understand the IKE <-> IPsec API uses this, but when does this ever need = to > go over the Security Controller's communication ? >=20 > typedef sadb-msg-satype: same here >=20 > container algorithm-supported: See earlier comments about all moderm = algorithms not having a min/max but only having a limited set, for > current ones this is only 128/192/256 >=20 > Note the version of IKE within the ietf-ipsec namespace only has = IKEv2. I agree with that now but earlier in the document it has IKEv1 > support/entries. So this needs to be made consistent here. >=20 > container ike-stats: does not contain encaps entry to show if it is = using UDP, TCP or TLS and on which port. >=20 > list child-sas: does not contain some "state" that can be negotiated = as part of an IKE session. For example, if narrowing was used, it could > be that the current SPD is more narrow then the "connection" defined = SPD. There seems to be no way to store this. Thus narrowing is not > possible. If narrowing is not in scope here, it should probably be = made more explicit. Otherwise, it needs to be better integrated. >=20 > container number-ike-sas: See earlier note about missing COOKIES = parameter here. >=20 >=20 > SPD related question: Is there support for multiple TSi/TSr generating = a list of spd's in a single Child SA? If so, a Child SA can have > multiple SPDs. Otherwise, it cannot. I dont think the model is very = clear on this aspect. (I speak from experience, libreswan as an > implementation is also not very clearly specified here, and we have = one known interop issue with openbsd's iked because of this) >=20 >=20 > // Those RPCs are needed by a Security Controller in case 2 */ >=20 > Please think about XFRM/netlink and/or ACQUIRE messages that are = needed if there is no IKE daemon. eg when max-counter is reached > or when a hard limit action is performed by the kernel. >=20 > I am missing an "SPI already in use" error, in the case it is = attempted to install an SPD that already exists and thus would conflict. >=20 >=20 >=20 >=20 >=20 >=20 > NITS: >=20 > Introduction: >=20 > What does this mean: >=20 > "with a reduced intervention of the network administrator." >=20 > Section 1: >=20 > IPsec architecture -> The IPsec architecture >=20 >=20 > Section 5.1: >=20 > besides the IPsec support. >=20 > Change "besides" to "along with" ? >=20 > With these entries, the IKEv2 implementation can operate to = establish > the IPsec SAs. >=20 > Change to: >=20 > With this information from the SDN Controller, the NSF can use its = IKEv2 > implementation to establish the IPsec SAs. >=20 >=20 > Personally I don't like this Christmas like boxes: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |IPsec Management/Orchestration Application | Client or > | I2NSF Client | App = Gateway > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > and prefer: >=20 > +-------------------------------------------+ > |IPsec Management/Orchestration Application | Client or > | I2NSF Client | App = Gateway > +-------------------------------------------+ >=20 >=20 > Section 5.3: >=20 > Moreover hosts can install easily an IKE implementation. > As downside, the NSF needs more resources to hold IKEv2. > Moreover, the IKEv2 implementation needs to implement an > interface so that the I2NSF Agent can interact with them. >=20 > Change to: >=20 > Usually, hosts can easily install an IKE implementation, > although such an NSF needs more resources to run and it > would need an interface for the communication between IKEv2 > and the I2NSF Agent. >=20 > Section 5.3.2: >=20 > It has also to send new >=20 > Change to: >=20 > It also has to send new >=20 >=20 > Nevertheless other more optimized options can be considered = (e.g. > making iKEv2 configuration permanent between reboots). >=20 > Change to: >=20 > A more consistent and secure deployment would store the IKEv2 = configuration > on non-volatile storage, so all information is available after = a crash or > reboot. IPsec SA information MUST NOT be stored on non-volatile = storage to > prevent incorrect and insecure re-use of symmetric key material. >=20 > Section 7.1: >=20 > Besides, fresh SAD entries will be also generated by the = Security Controller >=20 > Change to: >=20 > Fresh SAD entries will also be generated by the Security = Controller >=20 > What are "IaaS services" ? >=20 > section 9.2: >=20 > SHOULD NEVER stores the keys >=20 > change to: >=20 > SHOULD NEVER store the keys >=20 >=20 > it may access to these values. >=20 > change to: >=20 > it may have access to these values. >=20 >=20 > observe the traffic >=20 > change to: >=20 > observe traffic >=20 >=20 > In any case, some escenarios >=20 > change to: >=20 > Some scenarios >=20 >=20 > Moreover, some scenarios >=20 > change to: >=20 > Scenarios >=20 > Appendix: >=20 > I see a few "->" manglings. >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf From nobody Mon Nov 19 05:58:14 2018 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 E616C130DC7; Mon, 19 Nov 2018 05:58:12 -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=fastmail.fm header.b=BnB+C4v9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PTFsRhim 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 hzh3cY4lR8Xv; Mon, 19 Nov 2018 05:58:11 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2D9130DCC; Mon, 19 Nov 2018 05:58:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9D80F2208B; Mon, 19 Nov 2018 08:58:09 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 19 Nov 2018 08:58:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=QHu 0cW7/HoeDBS4EAuyMvpkddRJJbgKfxh4ofYsLQ/U=; b=BnB+C4v9UsV8wE7ctYS ukSgzhKsGK68RdPq+ivmGcWSoEkzhYJyeSpIf7YthM1oly2g71ieEDLpTke7kaEP YT/Oze61ed69Rfly7fdsfAfBX3V5eHG5Jh/UnFx1xsbEogApZ79mhEtqxJ2obQ+f PDK7A3w9IKHZZ+Ls5l9SJj0YhvDVeP54wc7lUtgtVaqFChalmvG4LgFcX9sFXRlk W17cflRx7jd0EWbdEc0sbo++cscx1F8vG0tG9S7qhL+7K2mrfRHwtTWFBYXOsQk5 qs7QQVxDiK2fcHT7krXTEEykPVYBbBxiVj2QEoFgwQgjIbBkyaPhqYG12tHrouuj iHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=QHu0cW7/HoeDBS4EAuyMvpkddRJJbgKfxh4ofYsLQ /U=; b=PTFsRhimH4M+T1abraf/+f5s5A5wT1DicSDiDF05+zFstHfusQqJ962oH K3bVS2DlwaCIGXr99E3V4rYeYk29I6uzJ6rpwmYNY949TfRes8u614K+TDHPSRG+ CSEPhLmbvPrJ3RXPZ2pi0blLi7nQJn/ug7Q6EBQwHqKVi2puCHQ7l7ja9W2qRnSu 33zRhCgO3hGtLttW0Yt06Se/QbZoCYPJFYQOlFqDcVM7BDs6FBwUrtONED78FUwM mEuP4hp8GlAp1MUMUjPory0w4MYnXEEqgSS/mhFnRfN++kp/VHPRrITGeWZADF2s No50ztjKcRtA2bESldcFcHFfZWDLw== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2516A9E1EC; Mon, 19 Nov 2018 08:58:09 -0500 (EST) Message-Id: <1542635889.4088149.1581869784.6FFDF4B4@webmail.messagingengine.com> From: Alexey Melnikov To: Paul Wouters , The IESG Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b References: <154247645671.15969.2304550137908278124.idtracker@ietfa.amsl.com> <559e3d1d-ad44-ccd5-e3ed-2f2ac88facb9@redhat.com> In-Reply-To: <559e3d1d-ad44-ccd5-e3ed-2f2ac88facb9@redhat.com> Date: Mon, 19 Nov 2018 13:58:09 +0000 Archived-At: Subject: Re: [IPsec] Alexey Melnikov's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 13:58:13 -0000 Hi Paul, On Mon, Nov 19, 2018, at 4:50 AM, Paul Wouters wrote: > On 2018-11-18 12:40 a.m., Alexey Melnikov wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a well written document, so thank you for that. > > I've noticed that Benjamin already found typos that I found and raised one of > > the same questions, but I think this is important enough to be addressed before > > I recommend approval of this document. Specifically: > > > > In Section 3.1: > > > > o Domain Name (0 or more octets) - A Fully Qualified Domain Name > > used for Split DNS rules, such as "example.com", in DNS > > presentation format and optionally using IDNA [RFC5890] for > > Internationalized Domain Names. > > > > Do you mean A-label or U-label form here? > > > I thought it was obvious that we meant A-label. Why else refer to IDN if > you would just put in U-label, but I'll add the A-label term. There are documents which allow either, so being clear on this point is important. Thank you, Alexey From nobody Mon Nov 19 11:19:46 2018 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 8E532130DE2 for ; Mon, 19 Nov 2018 11:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XqRRje_fDVgQ for ; Mon, 19 Nov 2018 11:19:43 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BB55F12F1AB for ; Mon, 19 Nov 2018 11:19:42 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 2B530C3C8F231 for ; Mon, 19 Nov 2018 19:19:37 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Nov 2018 19:19:38 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.160]) by SJCEML702-CHM.china.huawei.com ([169.254.4.63]) with mapi id 14.03.0415.000; Mon, 19 Nov 2018 11:19:33 -0800 From: Linda Dunbar To: IPsecME WG Thread-Topic: Can one IPsec SA be established via two internet ports on one device? Thread-Index: AdSAOsNUfG5n7pjTQrmo2gsquLVYHQ== Date: Mon, 19 Nov 2018 19:19:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.120.13] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] Can one IPsec SA be established via two internet ports on one device? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 19:19:45 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_" --_000_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPsec experts, In the following diagram, CPE1 has two internet ports, A1 by one service pr= ovider, A2 by another service provider. CPE2 also have two ports facing two different internet service providers Question: can I establish ONE IPsec SA between CPE1 & CPE2? (i.e. between 1= 0.1.1.1 & 10.1.2.1)? But the actual packets sent out from A1 port has to use A1 as Source-Addres= s, and using B1 or other public address as Destination address. Or is it necessary to have one IPsec SA between A1<->B1, one IPsec SA betwe= en A1<->B2, one IPsec SA between A2<->B1, and one IPsec SA between A2<->B2? [cid:image001.png@01D4800A.7F9B4EE0] Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPsec experts,

 

In the following diagram, CPE1 has two internet port= s, A1 by one service provider, A2 by another service provider.

CPE2 also have two ports facing two different intern= et service providers

 

Question: can I establish ONE IPsec SA between CPE1 = & CPE2? (i.e. between 10.1.1.1 & 10.1.2.1)?

But the actual packets sent out from A1 port has to = use A1 as Source-Address, and using B1 or other public address as Destinati= on address.

 

Or is it necessary to have one IPsec SA between A1&l= t;->B1, one IPsec SA between A1<->B2, one IPsec SA between A2<-= >B1, and one IPsec SA between A2<->B2?

        &nbs= p;            &= nbsp;           &nbs= p;        

 

 

Thanks, Linda Du= nbar

--_000_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_-- --_004_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=37321; creation-date="Mon, 19 Nov 2018 19:19:31 GMT"; modification-date="Mon, 19 Nov 2018 19:19:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAVAAAAC9CAYAAADlRSUxAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAJFJSURBVHhe 7V0HeFRV2v6mz6SRQkhI6IQSCL2DiKIiorL23svu2vsWW4yrrr+uupZ117auvXdFxIYiIL2FHkJN qCEhbTL9f98zM2ES0usE78dzniEz95577rnnvufrnzErK0s00mag+gx8nmeJsNpljFuvn6Dz+frq dIatTq/7k5lpjvU8Njs73bDDmDtJb9FP8Xqkm14nxaLz/rC3XH6+PMNRps3okTPAOZVckZmTHeU1 zQ9/jysU/eQMR6k2fx1jBowdY5jaKFt6BuZl+2JLoq1D9C59pF6826cFgJHXmbPBMsRsNjzmMxim 630iPvEKAFTMOrlrTo7+CTF5v/RYtt6I764WMeI3r4gOJ+qMdybbdN/M2WC8b9rAsiUtPeaO2B9B 0VgmZ+mMpjEmj7u/dNV5v95sXWJw+D6cluHIVvOdY5no9ummW/T6UaVWr+mbrdGbfQ737G7uXrMy MtZ7OuJ9/1bGrAHob+VJB+5zXrYlssSq/70h0niqzuUaCnyM8Ihh+9c5tpU+cb9lFPMBt9H3hslo 6e90uMTj0QFADaIHSJrMhlivx/uA16W70mA09fF6fOJ0+MTn0wNEcZTBJ2aL6WS3zzNg1obIC2cM LPv1aJ/eOTm+OKdYjzHq9Wler7fIKO6V09I8K3jfn+dYeph8uv/Tm0wX6Axm8YgJ8ySYJ/0Ml85+ wewcy93iM4zH9F1qNFmSvdiHMJmiNxpP8ni9V+00bHs1N9vy15kZjkNH+zx21PvTALSjPrkmjBuc Tl+P1fCMXqc/BS+0zu0yiMerE7NJBplMukFuZ/kpHp/XDnBMcdidYjB6ZOTAbdI7Za8sXZ8mubuS xGTS4/039PG43QpcM/rukGEDtsqWXV1l+fo+4rD7xGK19PKI/dHPc3xnz0zTFTRhqGF/ylsLY80J iY7LvT75I8Czj8/ni9WJzunR2/Z+vdn9s0+ne9vokxuMZusMl8strgon5tktbq9eXE6dWCzGAR63 vKoz6GN0Or2UlwNeDW61EZVVePC73mowm67D44icl2e5bnJqzWJ/2E/UUT5ADUCPwgf8WrYlqmuc mMVe4ZtfsbY4KyPDMyfPl+jx6f5ntFiOcTldUl7sli7xhyQ60i57CmKlrNQiNpspDnJ4nMftwode Lj/9R7QfxGJyyeadXeWeZy9TIMq/KxwWmT5pufzpio8kLqZMnC6jfPjdRHn+vRnidDrFaDRNsXoi zhOx//tom+LPs5Nj4jsXP6PTGy8xgFxOEYfDAM7Sa7ZavN11Rt3FXo/7bICj1Ym5Fp9XxmTkysSh G+RAUYx8/tNYKa8wi8moj/HiN6dDJ31S98rUsavFZnHK3KVDZN2W7pg2j+hNxsvK7O5l+OOZo20e j4b70QD0aHiKgXuYk21Jd1v107tYZZK7whel09m84yPHbZ+d652Dd3GKzmhU4OmBVu34sWvk3JPm S4/kA7JkbZq8M/tYyd2ZDA7TJXaA49Qxq+Wy035ULzQprdteibTZpcxuEbfHIMMH5Mptl3wm8Z38 9g6L2SUXz/hJtuV3kQ++nQTuFZpTndzxeZ7vw5mpuv0dcZrBQXe1ijXVLYKNRfbNSHOs4n0YLcX3 GkzmywGSUl7qk8S4QzJgUJ4cLI6WzdtTRK+HmG7UW31gT91uvZw0Plv+evUH0inKbzuyWlzynw+m Qy3iwFybJL13njxy0xvSp9se9fupk5dJ1gsXyIKVAyQi0iRej+fmWTmWb3D9jR1xHo/mMRszMzNj cYPXovU+mm+0le5tNfr9AJ4M7Sqmpqen65/6YttVEmG4zWg0D+KL60WjZQfytnic5X/Afx3CF9ql kxPHr5R7rv1AoiPsalq6JR0Qs9ktf3vhfHBGFnG5jXLsqLUSYXVUTpvLbZBLT5srCQDMZev6yiWn zpWkhKIjppWgPHdphhwqiwFASG+rI2IsuNCvWmn+W6VbgNVonU53pVlnGA4OMRVqy3jI1nu/3hLx K+ZxO9q1HuxCLjCXk0euxUYzVwb22iUHD0XLd4uGyX8/O1Fx5NxoUhMPyjVnzqkETw44NbEAz0cn pXYrpIAiufPyTyrBk7/zuxsv+Eq2YEPbV9hJIiJsfd2uihn4qUUBFO++BX1ejDa6VSby6O50B24P NgO/aHDp0X2vrXZ3VPsPRLu11a5QT8cLF8YaZ+VsfdBgNN8pEPjsZeCXYPaxABBhjwCHZAI3ZNKZ jB6ro0IvqQDL3589pxI8g92PH7JJfn/ONzJnwQhwSE4ZBN1mKPG7E8etkvFDNsruA3GS2uVgjSPr mbJPxmZslq/mjZUIm0fv8Xp+l5mdPZtqhPaao8ZcF+B5i06MdxlMllQadaCNgATug0pCoqEnTvN6 HNBu6PC9D3O0U+679n2lCiFRHXIxNpbVm3sqMZwg2rf7bknrsbvKECYNXy+P3/aqfIE56t8jT0YP yjliiOm9d8oJmO/35xyD54jX1OebuDA29tkJRUV8wC1Ft6Mj+jGaWqrD31g/JxJANfBs+lOHsCbH NP305p9ZmGC/Racz/ZVoabd7pWvnQhkLMBzYexdVb7J4bX+I6P2kHNwOeVJylx4YMqpTQqdiuep3 38n50+YpS7HNcpj7DD02KqJC+lUDhNDfLTCUDOiZJx9/bxQbOFi4Ol053jpW/3me586ZqY6i5t9x 6/QAbkw37tJH/6QXw0OwghvLsRHR/4DzacI9kbs8VBqBzQXXx8QS1E6bvLQSPIOjskKVcedln4Ej zVf64mkTlUG+CnWOK5ZTjlkOnecaiPvcg2um8dCZfvnzGLE7MSqd7rjCxfbzpL+83YIzcKYGns2a zROq60A/R3cdUl/VrGlo/MnkOicFTms3zuqHHMsxsODer4fSrbRMJyMGbpXbL/1MhvbbVnlHF0z/ RT79cbw89cZMJQ4OgKhpNNQ+5EhbzcDZmClKiC2FeGsAoJthmHIbDWbz1TBo2T7PtlwDlxy/3iDM aMzFj52n1xvuw3way8t9kgLR+7Rjl8qkEeskylYh67d2k28XDpe5y4Yoa7kD3GVBUXSNd9E9eb9c d96seu+QeuO6qH/PfKI11C7Qu1oNnTG2/87aJF3jxtqebmFOlMOYj7ah3kFrByRiCmYGp6E6gP4Z +jxtEutZJOBWqDcKAigZuzYnOmibRJ+pN5ljKuA6lNZjDwwVHyrurzqdcfyvECcNkgNL+rUQ3xNj i1t1vKMHb5Z//ull+fbX4TCEDAQEuMBp6S8yW+VTXPiDVr14Ezr/ISeyv0HveVhvMEaWlPgkvVee mku6ZwWpN6zkkwGmT79zmrw9a4ocNyZb6ZJbk+Kiy2RIv+3y6+qBSpVgsRgscEH7e+Fix15wom+2 wLVD2d9/491/qwX6PKq7wLtP5qlWAO10VN99y91cVMt11bSezGXGCT69dxwt6uRkrpj5fY3gGez9 7BMXkpmhq03TLtiIs5JgBDnt2CVCXd9DL50n3y8eKpERMGz5PH+F4/l309J0hY3orlUPzcy8Xzfx 0sevNphsfe12NwxjJXIbRPBQ8AwOgDrO68/7GnrLfNzbBuiBW9d2SL/RzD+8C51qL/n3+6dAJZAM q7zBJD7PHbNyfPNnpOkOI3zzZ6nd13Tzb6FNeqiCkZobU5vMectfBFq4k2HoiC4p0cuEIdsUd1QX GerQtbX86Pw9xsWUyqXwJV22vi/cdWzkQkd4fdbz4TX5n9a6ZmP7nXRpVorHZz1NEFWlhxP76QD+ cRmbau0mHvd03jRKu21DidCXngD/0AirU+7718VSWBwlVptlOEz8VyyMtf2tFUT5trmxo+QqGoB2 wAcJf894scg4WN1h6PAoMS8W4l440pC07XLKpGXy5lfHS6cYPfwivWdgnGEDoG6JyoAKeZDL5VGe CdMnLg/HaZQJMCidDIPU+3MmwgUKDmo+3aUlv5a8Ch+QbWE54N/IoDQA7YAP2muWMXq9boTT4YEV uFhG1eAGEy63Rc53MFyiaG32Ae5hCOk9J9uXOC2j/Z3rM+E/O27zNoS1QiqGFwNF8x5d94XL1B0x jrNOWCCzfhkJ/9EIGLKMvURn6ClSpgFoOz4xDUDbcfKbcek0g9kWzXDM7vDrHJmOHGlhTN2TC5Tf 6IFDCXDH8SV4IyKGwbn+u/Ye8qgXcyN1SXIqwZM+s1NGZyv/2XClbtC5dksqkPW5EaIzI72L1zUU Y/0pXMf7WxiXBqBt+JRhwaMC2ooWGbgsXXrssH4WNWYYPr2uK196ZkhKwUvF2PRwJhqVkhIKZXdB ZzGYfFHgRVPCYbxxXSW+VPRJjApi1NWw/i1pk2n5O6RRiclb1uV2V879cEcdyUCKCRNa1Lm+5Qd+ FPeoAWgrP1yAJp0FJ6Idh5aO1hmta+Cy9Lndh2NotfgFbSHAdG99Q0KYYRRfIIrF0XBsD3c67OdF 13SdW6/zhIUvqF2MqT6d10AApcGLVvZwJmZqSuhUEjrESMge+gnhPOijfGwagLbSAw7EGV+D7k9H OxbNVsOl+oR8dxv+vwDnfY3PlwGktSrjgJ3RehVX1DGowmlC9iazsnIjyAkejWY4orY/14zkctAo YCYxlYw2QoRmWJPPp1NZnA6Tr2hTdFc4shUdMW6so1R8OQCNG3Zy4ABu2GybsL4Yq9tuQSBhPdGN GJwGoI2YrIYeisVLjvNetOloVV5Lnd6AWGqDvyvIYMzoE6BgWChDQ3+HPh7DIv8o9Jpz8izxngpD FtyBzvS6nbDG6lV4YbiTDxwex3qY8EU7E1L+RSba9HCI1ln9OlByx+FPVcJwmSDmXAxbFVkRCWza DPC4EI2fBE8ukKDKiOmg2A7g2EX4JMgGqSPcftg9IA1AW/iRYGH+AV3+HY0p0BSZbNES06WXJPYZ KVGdu4sl0v+T014sZQfzZX/uCineu0UcpZX+5chgJG+hL37eByB1MsdnF6vueb3RdL6POSSRlJc+ gXuRy1NZt8P49d+xu4vs2NMZXB5Kg/ikBFntGaPYboTE0qlJNuN/4BFwitcLjQJKluTvj1Op+sKd +MyDuw9qVZVmrV+vIiOwVgiYmWj8rG1X5fdsBFZG1IRS82N4w33yWmF8GoC24KRiEf8R3T2JVimu dx04SXqPO0M69xouRrMNnE7VSCBm9ul/zAVyMG+DbF38mexa/QMYU8WV8m3+E5oO/d436YonrwOL cD5yQ0Ic1ktP5PFkrPaoQdCC+TPXIamvyFdIHHcIyYGGwj47alTVm/v0U5GDIUmUTj1VJCnJfwwS zMucOSJ7oYGlSBskG+7ktNOQaajmsG+ZO1dkK2wvsbEiJ50kElUtnoXJS+YtH6RSt8VEu8Xr8lkg OLYb2zwvOznKbSn6p9FsOc3jciD7u0UBUnek5jMiA384E8FzOYISSEz4ojPZ8jMz/8IZvwHtLrSE 0PHbYhLFGp2AOHo/A+px2qUCm3R5YdXsUIFzTsI6+wabtT8pqUYNmgENQBs0TXUepN46LD7mVH0C TYFnRGyy9J98kfQYOV1xoB5nBRIZMzcafw0iFN4CnM2SDom9h0t8t3TpkjZOcn55Rw7tqUxxdkd0 Yi8kMNCNZGE3h8Mtk4ZtUCGF1VPOlcC+cN11sEpBe3rLLYcBNBcY+/jj8F6v5r5+/PEir7yCRLDI BFuAqMTrrxfZvv3Iez3lFJGbbhLhZ5A2IGPCv/4l8vrrIsXQaKbArv4LzGDVAXTVxl7yDWLimZiZ NZT0JksSMmmehX7apV5SmfXQ+QaD+Ry306ESS9NxfvKI9Ug7t0e6Y1MKZ/phyRApQNJmfwYnlAap KD1VbzCN9Xpcl4SOO6nfWEnqP17iUgeKBQBqsvp3NZRsgZRzUA7lb5Z9ucskf908RIVWqpCY3yGR EhRAdFs4z0M4jU0D0OY/jXIsuuPQzVPETXYXGd9Vhp1+u6QOPg6L1i7uWsvZ+IGUOjg3ABbJLKTP 2NOlU3JfWfXFE1KwfQ1/1kfGp1yBSmM+pljr0fWA/PnKj/GyH5k0i1wJOUECaESAx2PS3ycA6wTP ATApPAn+OCZGZDeYkAceENmGV4UASu7VEFDNXnWVyJVXigQB+WuYtTYile/s2SL9+ol8+aUIj9mP IfCaJF6XmdhDidbt+SvTpQR6Wj1i8A06JBUxoQ6TOEchM1Onti6Wpipk+nw38TZdSBE3Zcxa5PNE YunIqlWGOWcVcG5Qaf2wHQbnJXhvnJcgIU+oOiZIjBIqqyEozAJ5whxq/wmcYIfhn9x/kHgMj61O O/cmyLuzJ0tZuRWVASr8Oluv92RLVJzYD/ntjdy0B069XLqmTxZbdGds08g/QIAMSD3miGiJik9V 0lC3YSdJasbxsnHuG3Jo9+bg5abhP69gPV+tgeiRz6CmbzQAbdg81XVUf/z4NzQlJ1ljOgM878Ai nkQO4QiRva6OuNidOCcutb+M+N1dsvTDh6QofxMAOYU8K7yXfCilsbVG8Kyt3x2wtRLwSOQiZzCv eYCm4XUJffmDYNgfd3RMIMtpFtLtXo3ixeRi5yMEnABKgEmAsPj00yLrEIL/0ENVxf5g/3rURL74 1J/wwjvk619GKT0ji9FBa5FmtQp6kqXNn/6G9xBllyEOnW4AOWFm4L9w+s9HgCd7o6rjxhvxQPFE P0DuqKAqhBvTf/8r8vDDsMQEMHcgNImvveY/hvNHNQg3H4IiOXN+EhDJ7d99t8gE+Bxxo+H5yxE1 evnl/k2MxI1tGEIMXnrJP8+hxDyjTFPIZNbM7Rphc8Gn1iLRiT0VgHaGfn3IjBsU1wlgFZfatI+0 C+EX1S3VSd2Hnihx3QbJ+u9elh0rsDv6aSravwGil7R3pYWGP9n2O1ID0ObPfQ90waZE8fQTrlLg SY4yuPM36hIBbrRTSpoMnvYHcKL/FFtcCoDHo6o69kO4YWOI3FBRkf8M6ipDqVMtubfIjQZp0CC8 bFglFHd37fJ/eybS8LKR/k5zWR3UGanzrjlrjhw3eo3c/sRVkrevC6J9dKlwxeKctSmAgukci+k1 u116JJzeI72QPb8m4pwRLE3I0x6cC+qVuZFwM+oD57MxY/xnEgRvvVXkhx/8HObOnSJ7oEUkmFIn HAd74XpYyWchPSjB9eWX/aDJ87iBjRx5uK8vvkBY0U8iJ58s8u67ImNpQgwQk4rc/4f3VLb/Vz49 CbWnWL8KyuQ4cJS9nTLqrL9INAyULkg8VZTYtTwbiP3wjHAHpKVbAcZW6OA/DR5N75G/AET/AhAN b8Vw3cuv1X/VALQFp7j78GnSc8TJMJQAgaoZixp3GR90pg6lFx049QplZYflGtEyLpU4pDHUAzBF 7ujHH/2iPIFhKniMK66ovZdQkZUcbBBEKOpXp1Dxs65x9QBYMeHJjj2U+ZFUz+upQaBtzJ01/lgw ZsP1eqPeiUJvLJkRG11aYyfB+yfnGPz/N9/4QZDGNKpDCI6kzZB+yYUHjwt+0jj3wgsivXr5Ny5y /tQbP/+8f/PpC1vQiy/CX+13hw10/I1gzOM/R2rzUACtRDZUQiUX+o/Xz4QzsEMSeg6Brv18iUro FuA6GzEv2E2omzdZIiVj+h9xfpnsWvVtsANo0+VnNMC6RrXNgAagLbQ2IuKSpR+s6dzJFfcZIPp8 ol4RdnuP0HezNuIxPBbFwxQHQWs9daJJ/cbJ/q0rVZE4isTBQnANHTZ1k3/5i58zyoFd6o03RN55 x288+hNs/KfTzb8aUbykno+NYjqJXBfFz6aSG0XpvNDb+Qn3IriZNiad6LtADwJuWi9dkXEedaIa PIKVK0VlQeqKGLLBgw+fRlG7urjNX3ksuVYSNx4a4Aig5OIpstNL4pIqph+/twP10tQtU01SG/mN SJg+rAkCZ3TnHspAVM3luMH35sG6pKFz0IlXw8C0SUr2q02aKikwoZnfgwutqiRucM9H/4EagLbQ M+4+7ETp1DVNPCwSHiCK9G7s6oW71ivfT1tsl2pWeK55lDCDPqq0YJfyA41O7AF7EZizAIiq3y0R qB0Op3sYZZriOE9RkaLhXXB0WbbMbxCixXzVKpFnn/WLlBQ5g0YgiuWPPuoHAdKQIX69X00c6OF7 hRGDUf61kA2lfAlYKoYf9+f22ds8gS+ujS0B/Dx0yU5ERzWGyMmTyB1yQ7od5dgIpBTzG0JBnSnn uLZzyOEqwxw6nFxHpS1upIrw0Pg/AmBTwTM4drp0RQGIKfEs++gRbPYKwUegUWv+YUPu8bd4jAag LfDUrbB4JvefqDhIny+oQAS/Aw5y76ZFsvSDh4T+oCOgp0ISJYjjfvZCh7dJbzDL/pylsvKLpxSI nnDjq8rZXh1DyxGPMVIZZ1cF4Xbt7awMSY0luhm9hYIN9AMlOJITpa7uKfgOnI8UxxQ9g/6fBAY2 gio5z7/+9Uj3pOrX9wDcF2d3lxlJeSpHaXUiaDGUk9ZjPS5mdEmbi/C4n1IF4ACgopIoxYnWl6E/ OCfkICdORKztAv/csV0LxzWK4PSnrU4ESuo/SXmossLzSDQ60RuCRJ9b6kWpXz4ADyo+Fz6n626M ksnHcR3VzIbGIGbfH9nFhCJBEz4eVpDBDw4m1KH3yAdSVVfKDRtGzGS4P9ENavd6lTSaF7kWXOjH 4EKrOjA3dgEepcdrANoCDzau20CJhfXTQ/E7QCz05ig/JLs3LpAeI6ZL2YGdUrBttaQMmqwWOmBE LeDcXz+U3EWfKrSyRHSi40llH+plR65KkzkCfZUiDtqq3IJYLqOpFB8v8thjfisw/TjprkNrMV/4 4PtGjvTOOxt3hX2Fsap8x0FHtlxyyuxK96ZgLweKYhDpYwVgQe8Gbgcq3SpZMRp3taYdDYjYRF2I 2eTVrYB/agEqbQZLEtfXY8+efp3lP//pNwSRaC2nVf5v8MG47TZ4YIRw4BTfyfHTW4Gc/hp4pHVG /A/VJkFOPztb5LLLql65R3eI+ftT5dO5KXLZ6aiQKkem1yssjhRDNQ2I2mRJAd07pR+qgUJChdXP /F6HjZ2fVCmFBnbwWHNkrKSkHyv7Ni8JcLaqZvwktHn1zdFv8XcNQFvgqcck9QFnGYXQzBBMwFty aHeOcloedtqtsmneW5K//mc4OI9VnCp1cRXFByRv7c8y4LjLxFFSIJvmv1fNguqD/tSo9FP64v2i g86L5TGWruuHWuKVvnt13gGNPGyhLzdPCBp/6C9KTomiY5CC4mZDpibo21gO/8TSilj57xenSWri Xpk6ZkWV0zdtT0Vp4Chl0fe6HftF726cNawhg6n/GHi0+h4wGb2RW1Bgb9n6NJUtv6FErpwGJIIe rfFUf9CP8557RAiwF1102C+W37///uGe6TdLAxHVIUEaDWiiKoUcKOmZ54zy0Qc+eeGpnfLV992Q pnCsXDB9IVGx8hwHVA+sjWRAZVWCoBlO8pRW1s35j1pr3HAVUGL9pZ94DdyaBqgNi0Q9O12cti76 RHbCWDR4+vWS0CMjRDdPLtQjiWmjJCa5D1RPUNqKYMuVE9A0AK1hoWgA2tC3p5bjqJ+Mhe6z6k5P FlMnezcvAvhFqRj4Pfj/nvW/iKOsUBhix+MJjKPPvVc5N9Oh2QdDU3UiF0pw5nWYB4KldP/+ytly 80VfwJK8S6U3q0kMDfp00gmeL/iDD/otwqQVwDZGEJFoEaZOLvgSN2Q6qAagdZ4UjFzyeZ3iLsmV XfZUef2TETK8f67EdwpYUXDctrwuUlgSCW4arK5Ht9llc29qrt6uIWMNPaZwv21zQhfHfKgQprmc Hnnxw5OFblbDB+Q22KBEVcdkCBH0k6Ul/pxz/MYicpkE0CB3SW7zPeyHQYMTOf/quk+6kU0ibxeg pNRoWbPeKpuydyOkd7n867XzZfzwndIrGRbAADGccwNKLBtRWplrjFFGNFAy6CI6oTs240txpE7W //CqLP/kURl3wYN+P2Ksowps0lxnO1d/J05IR86yIgXCocRouUisx+guvYMAyp8HQ4w3aC5NR644 DUAb+xZWO54LOCK2axXwY3y7uwJgh0Wd2BMx8NYISUobI3lrvpfCnevEhggQEkqQizUqXp1bE3jy GHIMBE8bRKtSOEebjG7ZvjtR/vL0ZfBlzJdHbnpdunYuVP3R6BOMdQ9Gw9D4QW4o6LcZHD45Jorq FDNJ5EiD59bHgX4Ik8IfmDIlhJxlBbLhB8izoLI9Z8n3J46Tc46fo0R5qgY2g+MrR9x5fATmxqPb OjNVBw1g29LFE4qcs3Mj/+nzuEaazbrOO3Z3VvPI6qGnT1kiY1COuaHE+6JONBFBtgTQYEBCUA1C oKXFPphroCH9DuhbJKOGmQCg4BYtbtl/sJO8+eXx8ter3oTI7lft7C+MwfPvgr/9HKgJa4P8KZ3q bZ26KOBDqWvpO/5sWfTOfVAbrVI6da6vNd88L47iQniLnC85C2qxC+EG2C+j4cjFcv2B6NbfC21L Q+7jt3SMBqDNfNoG6J5MSNYQqktCrLVSwjNpQ+epV6rdPxailMkWI3tgVErJOA5XpcbfH2oXFLvq GoolspOUFxdAL+UAx6mDPtEm2/MTq3BO9FGkr2ch8DTo6M3IFjpokxMNEl/+KVNgYqWNNUDkmGhQ otP9+PF1Two5MIaEklRSi4Dx4tfV/WUhapibYgfI3MUlcvLYXyQmqlw2bu+mVA9WqwfipMeNRPqL mjntTT59ep+yr2dtsrxnskbcYPZVKK+GVz87Qfp021MjgAY5yv/9z68GueCCw5emiE5OnPefkeH/ Pui5QCBlLffaiOfSiHfzzYeP+PFHn8z7yX8SN2UznvnCVZGyeXsKNkt/FMPcpUNgTDQgqMKjQNNg tsD1LWC45EUDOlCXgz6uPsWhqnR9EPO7DpgEp/vhyPy1Feuu9sFRJRCb0l/M0MkHMoQFg0U0AK32 QDUAbfKr6D+RLjlGiNhcpH5AYe5Lj+zeMF9FehjhpFxemK+Akplx9ucsk5K92yQ6qXedfqHVh8WX xM+lwnIMA0IUKkj2hHN6FOKig8QXvLpRgr/R8stWFxF8yZE2hNLTkVofrTpN32WUG/5+ghQeMsja zYeUkYZZ3t+aNUV2gGtmaKTb5dngifTCE7V9CPHwnYw6XS9yVsojAJ4BiXGHpBtqNgUp6INZCgwK AiKt5QzrZFKW4IZBIxAf+w03ICkJY3dAwXMpAQTPrelO6ZNL4xOBOQjSm6DUoO8tn1XKiOFSpIuW fQed8G7opwCUovuXP49R+k+CoxVx8Cq3rFp7OuUIb6euHBwkxXSK4gm9hgXWjU66Dz9ZeXQEdJu1 PgBm/GKIKI2aAQBFkKmwaVRtBjQAbfaSUJUmK3vRAVDLDuxSMeyM8Fj/PcVa5MHEMa7yYnCRe2Rf zhLpBI60Lsf6qsOC3yIMVPT3q3BGyhlTF8mFp/ys/ELNYVQPqUdijiR12i6FB7tJSblN1mzuKQtW DZTZ80eI1Qw1BWLQIdq+eGqqo93SHllL3Bkeo20Gyxhz8znnxIVKPA6txtkF7rrk3CmWE/RJ5M4Z kcUQzKCYTq7zH//w6zGD+k2K7DyXOs/guTUtsTvuEKERiRwoPSFIFPnp/cCcBf/90i2vfYEkM26z 5ED9cRCb0XPvnSp7IdZbTRViRMCGNRoX4doDotM1bM+mX5UrHDdxcpnMyKSs7gpusXkBYI0NySQI Lpaca4hkBJSuTMrc7DfmaOpAA9BmPk2KRsy4RP9OLlKECsrBXeukvGi3jL/478qAxDyM9Al1VZTJ 3Bevk31blqocoVz0BpNNLVZGMJGL4P/NEPWd9kN+Z2bqocARkCvwovyEzeoU1lof2Msv0oUT+WP1 dytOiU7zb88+VnaC8+QLbLLAeb6i4usoZ6dXoZVt02G/VVBgiSvtMULv8kK/YJgJgNHR95zp6645 65sjDEiMCGILJQLjRx/VP+wzzhBhq48YJsoAB0Yn1USD+uyQ2KhSqBgiZQus7nc/e4nyGrCYnQog I+OSVACGEtmB6JRwmP2L0USUig7uzIYR6TFZ++2LSG5zq59trssvtMog/MEOwTyigZ80DrSGB6UB aH0rvZ7f3Yg8Imep65SkQJL5Fncis008stzEpQxQ4KF2crqcwBDUc+QpsmX+B8rFiQlD1s16VnGX jFaiK9PqL5+GMSBJeo6aAVeSvsq52cMwUBqaAKDkOCNCxPZmDr9FTycn1wUVOP3kk5wdXWEtpheB mdzzGhg+7picsYfKuTahdNR9f+KLbecn6HueC/XHBL3ZmsxifNQji88I0R0OsGFKCZ2KEdnlVL6z nEeW8jCZ/KK6NSoBawTWK27Zhz2cAoEZdGOCWqLPKEkeOFF2w02uouQgPD8S1CbcEPJfBQ3rWaO6 Z0CboWauEHKfdgBfLJzpfQzjxE7ff8olylXJYLYGnZEDnIJeeo/5HcB1sD+sE0qyePjhMV8ooz9o FCCXqqyr5GgDbk3KQKUAFGGdRq9KThyeBAs7DBxBgqVb6eigqpir97pvmpbmQF6ihhNcZ3T9b366 co322SS+hpbwnZNjSPs6Z/ujkAhmwP/R5nC5xV4OjwZYr40BjQuTm1AHGo6k7EEEMSCZHl4dRjPy JGCdlBXslCjkXWAEG409QX0s70HPvAtYQ8wX6EOkAjdz/k1ukv3RD5QeHeoYQKTBaPFXSYCu3h8d 57cGqgIxWG8ue5W9TouHr2GhaADazLfHVVECfVMuktNOUZltuDi79B2tFqA/RvkwEQhN1mjopsYp 52YekzJ4ihLJqh7nj9bhwmYWeqXHwsvBJBJMqLu3IBAj2Myxt/zpECXBJauXkLo5n2e/x+t+3e0t f2Jmmg4pnOuntxbGmhPjXIhMkIzxlzw+VVfkQN4iSp8+XWGilM3JsS3FRCwAKm8EINeY2++HHMM4 r1iexQY2hvlHD5V6JM5WLv0TDyDIVC+5ByGPg/YfjFEJTg5Dfv3ja6sjjDAUqdBXFbbm81TAOJS/ dq6hdP8OVC2A8rTamuFGfmjPFhX5RkmoGBJOMf7uhQ2bHhxezEMh9PJck4yIc0HqKdixWhmVIrCZ U+qpdKVD327kpQ3R0RPLYRbTqPoMaADa3DWBrZ0ASn1lMHyOi7k2Iii6UZYjSLVnq1cwpLKKU1eq ABT+PyV2uLXsTG7uqFvlfHKf9FNUrk00LXvd/5zR1/5IQx3mZ+VYjo3v4rwEtqbz9TpjjA7if5BU n/gDdrMzVKIVnWHF7BzbSygU8sXMNEelQnhOTuQIHPMmgCHN4WDlUpFx3XLkzEG/ykl9V8n8bely +zdXqZndtCNFSstsEtepzbQKDZ73guIYsaMUtBGhWx5H8Z6Nc18D97kr1RwRA3Arqdx06f3BtZGK jZiRSNuWBLPP+STjlBulC0R5r9fPqe5FeOahPfB1xR/dhp6gsi4RkKlWosWeqiK16vDsKFVRdx8g TlCbh942eLLa8UANQFtg8ktg8SxFrDsdloNhcy3QreqCRqnyoj3gKDaLES+PxeyVdVt6IDFxgqR2 KWipy7RIP+Tmdu6hbo6eCeAa9bK1IR3PyjH0h3b3z8gfcBZE01g3xG2ni9wsXMIqU+DxvfcnJGH9 dqPRNAJ/P2/2eS6fnaN/enqa/Z3Ps32JRov3aaPJAvCECxnE9YuH/ySXDJ8Lg4yfgerZaR+4UWTI wkZEA82Stf1k2sQVDRlmmx5D7phVQk0WuCfZ3TvKDyoGPpWuSsVwg0vqP8EvpfjAqYLjHHj8FSEu Tf6hktv0S0H+jWjgCagMg/WkQJKZnAJGJZWbQOVx8EtCer1Jca8VUAEEiEEP8FrVqPoMaADaAmui eN9W5ZoUjdLFjbN21n9xqgQYTbL5l/ek35SLoVuNko3bUuXj7yfIDed/pTILhQvl5iVJ/r54BXR8 Ob1e7/b6xjZnk+V4cDz/hLg91OX2ImoKmfchvnaLOSgju+ZK/4Q8BZrkGHcWJ8qavT0l52CylDmt CgSsFjPEdffLs3JsgxCA0wtgMtmJME3S9aO/lktGzAWw0KudyICEHpHFMjRpq3yfO0zsFWZ5/9tJ Mm7oRukEh/9wIeq66Txf4TSLFZFbupjOawCUDAmaQI+MIhYcJPiFWNbrlmT8d6YKG9Z6k4fVSHpw vTRyhjAD8FCVhodphctEtsE4NABtgUmmC8mO5bNUMS8rrKMqI30LEPVTzOjE6omlBTukAImVWQyM CTnemnUsQiINMmVUtoryOX7MGknr3iA1YwuMrOYuvpo3RooQ2WNGvLvP68jBMOv0tZq1yTYD4PmK wWRKrqiAIQOYMChxl5wzaIEc1wux3Rb4OyqncT95PTop91hk84EUeX/tJFm0a4AcBCcZYZEIvU53 L5WZ9FZweYxyfsYvctGwnxSYVyY0AgTRsf93/RfL4rz+YneZZfmGPvIwskj9/uxvFEda4TDKpBG1 +Ba12sxV7ZiJV1i+2Ayru8dl99o6pTCRB0Id/KSSHkPiYfHClpZ4qA6g8al4b5Wgo3WIg29b37M2 muvmXkYD0ObOYOD8g8hcs2PlNyqZQ1AX2qyu6RwNcWs/OFtyt6Q9G36RhD4jDkbGdY132L3yNkD0 HVRqLIXTejGA66YLv2o1x/pfVw9AFqi+kpJYKGnw9WSBs1BihqAfFw8BCNLopdij56alVQRSjhw5 E7CSZ+gMun8i21SyvQKeBUannDt4vlw54nuJiQA3SMY62AKnk9uOMlTIiNRcGQHudMGOgfL8khmS va+nRMBRn1QOUBwGDvPK4T/AoAfErJ5SE4dN7LVBTu67XN5bO1kiTA75ftFQWb25lwLQXl33SP9e +a3m4sRkID8tGyydUAk0HrpXRhhZUDAulL5ZOFy2It69U7SXtbA2psYP+wq/90crRIsrgq5zL5zm +048B38G3eSbtdoqTzbCc2Q38tOGRCtR9xHIZtoy1ziaetEAtAWfZs68dySh+2Dp3JfO8+RCmy5e 0+UERgNZhwQdQaMU/EWzHYX5d0dEdf6z2WKa5IFUR8mOZW4/+3Ec8oQulQGt5GD/3aJh8tLH0xTX e925X1cB0FJ4Brz8yUmSj1o9FjjTe1EAD5zlMbNz4egNMR7xU/Ngha9U2CKcsjsyUj4PPWY/gmeM xQ5xe5acOwRJfIkHR6bAPPyUglPKZB59N0hqdIE8PO98Wbq7r5ig8zTp3XJC7zWSFFfkF9urEzDV jGzO14z+VioQ5TMrZxR0iD7Zj3yl9B/YsK27fDF3rFx15nctuDIOd5W/P0HufuZSlRe1X898eeNv T1UB0HkrBsnnuL4NyURYxgXb6Kdpug8JnIiBUkCG9M0+ycv+EZ4fxynf4oZHtNV9S+Q+uW4ZhkzJ J0AU3ee2ymQcBZ1qANr8h4g3VVkou3PRrfv+ZRmb+KCKe2+qeEXHeyr/N8x9HcajSlGKsPLQ+VN6 fzEnx7kMpoPbYZI+C4xqLyOYvmKA2BxwLq0BoHTiLkMy5+hIitRu2VMQK9kwZPXttlfW5vSQ9+dM krnLMvAbEvjSKgytJQw55+AezvHpdMUmn23L1zm+X5CH/tXo/aY15kTH9XqTFbpKpPQD4F01/Ds5 dxjAk1q+hvl6+/cmMG49u+6XU9KWygKI8+R7e8fuk6l9VtfdD66REntQ7j72AxnYeZd8tH6i7C2N VSuhwmVUCVHOOOFXiY9peet8SZlVRZNxlpiacA3mb8TAreLAdb/HJvVfVNxk2KYNuk+ogvItHpdK 3wwR2gW/WCYhZNS9oWD7atTKWqFKE3sbFWVU+4Lnpn0A/e4COIfQ27g2AVyjGmZAA9DmLwu8rfIu GvK7i+7A1lUoRfyUDD/9duhDu/iLfTU4hA7WZcTP0yK69psXZNtSSm6VhBBIUcGE9H/Ey3TXiZc+ +mip6O/Cwv+TCXrYz+aOk3FDNqH0LXX+RxLdYvhyEiDiEelCvWlVD9SaJ4OJkOmexBRqNoQSUj93 2+PXIL7dqVLUUfSFr6K4vEaxAGBdML8fKjYgatICjtQbYzaito7PM8LjcZ9flFjxCw4e54ExhIEx Zw1eLBcPm+sHxKYUjYDxOK8kAaI7nMJ1Rukbv1u6xyM7dH1ADPCNslbIZcN/lJnpi2XJrn7y+Pwz xQn96bINfeU9qEauOy8khVXI1NDIwwghGs12wOvghLGrGhzcsBlRRSQz0hI6nUa557lLEXFEa7oO ZUYiletSBMAT/qt2bD53Th3oyQ25NBcEMywfQ737prlvqoi3CIR1htbiasqSpiWfEXGbf35L5QkN EP1skdVUo9pmQAPQllkbzBgyBu1KdpeXPVf5hbJGfHyPwYoTrV5aofplVVy8EbpMKO83IzP91sWf hR5C0e3v4AQqhVv8H5DjODBng+/fEOTPM1ssvQh0j792hjx841vSvycK8VSjpWvT5PHXz5ItO5Nk VPoWGdZ/KxIy189lMf/k1l1J6qUn4pIjPQhdng8Ol/Qy8kDvaYKxZ3KPdTK861axQzTeWxIrhRVR srmgq+SXxONcZA8yGbvgjLMYUOB0eaVP3H7oKr+DM3eIoaeRz4N708iULXL50B9lO6z0k7rDAFRN d1prlwRZjD82okxO6r9SlualKb2oUeeRt74+VlKTCmTmlMVHnM6SGs9/MEM+/WE8wK8CFvwymTwC tY3rIc7bUrhNkWjcoshcXB6l6jORWJUjItJEkfwA+M+7ToFrVmiXeOZl2DhR8k+Y6z6yaPcmVDp4 W4aeerPKLXu4PlJ9I6n2u0pGYpLtyz5CGkbsb4fpSVyzVj12I69yVB6uAWjzH6sVi8yBhY3Sayrl 19nsknqk4n3bVGLbHiNPFgsSJ/srHfpdfPwvkYo4BoD4d39ynDkL3peSfVW8f5bhoGtxjRp9KqcN 1G2bk6u7D2/Pf6xWXeRmOIffg8QTV5/1rZw4blUVKzY5pj0HYsEtoQREbneV5SehU93eKfTDXLhq ANKqdUIKPbjBgLukHhRFl+EW5JPOESWSFrdbWc1PH7gEGYgOp9crL7XImv09JXtPT/lh61BZdwCZ 1HEOG0XYeFuxxFhho2iqqpimKkwOjUITe29QHJyZmdrr4z5DnzmvzW0JFnxyo2v39ZDsA91hjbfI E6+foebrrKm/SueQuPlCAN4ybEYUuyucUbIIBraGAOi63G6yNhdVV6lsRaIlRP5sgq9qEnJ6JvBL SB4HPS7vbIjur8wY6PqhlqWJxHqCivNyO3/fvuwriYCkkzbpAgWCwYKFDV3WwbLbO1Z+Kxt+/F/l 2sT55HZRBUqjumZAA9Dmrw/1+gPg9gJEmaedposL+V3ZwTxZPesZ2bHqG4TfjUXFw3HwFe0JA4K/ ICVdbgiydE/as2khMuisq56ZnqURCZ51xpBHj7S8W7TMno6I6bsjIwwqe8/DL58rn3w/XmVHMsPK y2qe2Zvx8oLzMVB8dJnk/W8mwxi0vU7xkz6ns+aNVoYOirdRZrucOWSRHANukxSF1GpdIg9BXwg1 MEXwEA+uCItDxvXaJON6bpLpA5bLF+vHyAfrJsH1KBocq1uB6zOLTpcbx34lkWYm+Gjiwwjw5eQk G8x9Vr8UQDc1vkBuGv+l3PfDxbK/vJOUQkyn4ewnJDEe1HcndL57JH9/PCz2PVWuU4reTG48d2mG nHLMMhnct25m7Z2vpyjOnVmruG9iH42G+9U7CE37BMpgl8HnKI2O27duQkJCrX5wlEKwzlAWUBV6 G0fpZt33ryjg6zfpPJV/wYucDKEJvmucVWze1HlSvUTvkZWfPYk8DJXBRryRv+FaWvRRPUtSA9Am vrM1nYYFV4DFfS1+o170RrRUHleUt1E1FvOiYzwz2JNcSA5B52YX4o6rEdMEvYX2EPqsMd479PgJ RUXut2ILHkgoTCmDdPzXyChzlMNhE7oeMQUaxUW+6PQfBZeqyjQYAN6/rEiXTyCGXoTcojVRcVkE 6gZNV0Yjitlx4Bbvn/KuHNNrHcpGBNAuqLus7i6kdgg0bidgE1M7Fcgfx86G+9FWeWrhTNl8sKsq zfvm6uOV3vTWCZ833yOnKTrU0BsHrhHsM497D8B+qqzd30NMEOfXbuku67d1U/pfJ7hOJ8pL03KP LK9ihfvVTmxOr3xyojx4/Tsq0XVN9NF3E2Xe8sH+0hyYM+QMgNZG1x3Ad4FX7zswvWdZlv88lPGs hwKbNbKGyv/QBlGyWffdyyoXaP/JF6pk3XrkUFCqo8qyx/5OFcepkolgg0feWko8DP90H64oy/Cj P+Ea7VY1oL77D6ffNQBt4adBPRW6fBRASj+YP6MdH3wrCJRsLO5VC3HHp5HgOfQTDGpu0AgvTkhw SYLjkTlQi7m83usMet3kmFibyetlxnIAJ2sROcuoil0IkI00GY3DK8DnvPb5CSoK59TJS6tcZw8S ljz91ulCtxoj/Clp5LhyxHdybN+1h4GxQSPDQUExGUA6rtdGeSzmVXls3lnyw7ahkmArle6d2i2/ ctU74DjBiU7qs04SI4vknTXHyvwd6YiA6ix6BOhX2Jkqjj4GXoSE7pHecXtl+W4UFAR3/jO8EJ55 +zS56ozvJDlQo4qdU+/JqLHn358h5Q6TEt/JyVMSQOAVuFFdZ4DaA19vlrGGCMu101KL6t0w2S/W xxKsMercaZkfwEQgFOcPIGqt1+jTULpjhMQk9lDeICrpsho5MrFi7RXvyUUikTVKZXQIetQQKsL/ r0ffmuGogWtbA9AGTlRjD8MiXIoFfh7Om4p2LNrJaL3Q/KmADhMLClNkIhtI0P2eOtXGXi94/LT+ jg9fy7Z8nWiWU1DYbgRUlV0YPo5CbkUQ65a5peIbq87aF2GWn9siTEm0rv/9lXOUcWMwEjVTP3oQ RhK61DCjvB6uSU6PSWb2XyLnZMCW1VRrOQcYcD3qEX9A7p78oXSy2pXhaXp/qHmbyz02dcKqnxcY Y/8u+ZJ5/LuyLD9NVuT3kQPl0Soun2rrLhGHZGz3TdI/Pl8e/hmqkg3jwYm64M51DNQnXaF7Xqki nhxQk6xG/fkflgwFeCL9HCAsKaJQ6Voj4cD/6frxsnwPEk9BpWIyW2d47PYX5uX5Lp2cqiOQ1UtY J4uxxlilCYVG5ESeQN/htd/8R+nc47vDQh+bXCnxuB12lVeBjvhM+F2NVuHve9Hnl/VeWDugcgY0 AG3FxeC3lMv3bFjoL+GT8hlz0ZGVCUIK2dGDOLbeuPGGDvXyDGScEGHZxQ8zM9P1554ruoyM9QHT CvkQR8GcXLkTTMvTkZGmeKfTIh9CxJw1f6SyptM1ieK1GWBagcieaX1XyB2TPhELQKJRBpraBoxu 6Id57+T3AdjN0H02dEKachz1qpiqUT1yVKMqggCq8ocGnx5A/4axs6QUcflztw2BaOyByqSPrNrU S7l4uWBsK0dCEDOipBBaIIkRxXLnxE9kavoaNaIxKZvlP0uny+cb6cDhQmZ882ml5bpH7r//Tzc8 +KBaO/US1s1KrC0UVBbq32lY4vpS4ZjVLOr19fU/DTzrm6Ijf9cAtPFz1qQzsDgZF15nbHiTOq7n JNifauTtpvVxvDknRwo9Xl8mxP2RnWJRqsxtgY4PLzKMHOS0qOub0W+Z/HXyByr0sM4IocYOHnBe CZ4NgorGXqAFjue4gtFMdDoIWrkIroExJ8UUyUNT35I31hwv72dPkn1lnaBvNipXLhJT8rEU9Ygu 2+Wakd/K+B4b/YY2nJ8cVyh3TvpUAfPnG8epfK/ISPX7iZc99iuyS1E0bxBhbVGKeQhASsv5FWjk RnujIRSsRuIIKPWkoAWqPmnp6ho02dUO0gC0KbN2lJwDh/yvPs+J/dXoc1zgc9qPQfLmHgaDdxyz OFe4TTIJ4vUDx7+NjEdgGesKr2zqfISL2N6Q8dc2VmwEtMb/YcxsGdplG7I8DVWO/cE0fLGWchmT ugnRUsslEm5gioMPbhh05ofR6fpxX8veslhZkt8PfZkNXqf9ls9zfN8g/JVp5BpMANIVOHgFgDQe n6egpaH1RIsIdMK7ADut6rszSuBTtAmB3zQsaPBMHz5Qm7QmTNrRdMrMtCKqEBhF9a/ZORZ4DhjG MiFIhLFCOadbrXjLa7KwH02T0Nx7CTjkT4A/KpvdblZRWRT3o2ywytOGw2Nq2oQwt8mxhXLjmFly +5yrpAAuXhFWy0ify3cNWNWHmzI0ACkt6fTiqJMAtH7rkkZNngENQJs8dUfXiZnZ6YZxtq3nGg0m Y7ldL6f1XyHD4HIUNsadcJ/uoKcBxsmaVbag7N+Q+H6oCYakbIO6ZKm8teY4WO5VgMU1c7Yb3prW 07Mt3G/9tzw+DUB/y08/5N7HWXNH6Hz6gW68vNHmcpXuzWwFyxSu9evC+bk1RTUBzDx30HyZnTMS gQYxcG8y9/I6dPDgsDNMWKMwnQENQMP0wbTDsJAZ3pBY7tTLqK75SGwMG0NjQiLbYcBH1SUBuqnR B5Vl/muk2GNkkU/nuwBF9t68eEKRto2F6cPWADRMH0xbDmtensUK7nMCyt/qvBU+SU/YJZ1j4dOv vbZt9xgAoDpEd01FLlMFoLgy8gWMjU60s4KgltCj7Z5Eo66kAWijpuvoPLikxNhHb/QOcrl9SPBR KkOSWswl9eicsNa6K4jxA1ADKgX1oPaWJYhBh+hRrwzWALS1Jrz5/WoA2vw57PA9oJJlMpzqkxCt JAnRJTIASYY18b0dHitrNiE7f5/YPZKH1HyIlTd5jXoCaM2JSdthiNolq86ABqDaikB6Om8XlLKN 9TiZs9OpQhWbnBlJm8+mzwDk9kgU0uvRaT/i5PV4Fgadz+Ma1PQOtTNbewY0AG3tGe4A/SP6JdFg tIjP4UF9onKJRJJgDUDb4cEBQA1GryQgxypdmQL5YutPz9QOQ9Uu6Z8BDUC1lcDiZV2ZnJIlO5KR haiFCz1qM9yMGWhIyZVmdK+d2swZaDaAIpphKMYQrFmdE8hVyOfOXJjMPGRFo1FxJ37byfHiHF6X v3cO/B68jU2BuN4jbgvnMIlhL7TdOIb5MjVqqRnw6SL4gBg5Y2PCEI3adQaQsbVdr69dvOEz0GQA BaAxvvYKtHPRggkuS/D9k/gbhWlUOQBW0GLcLZJSSgJ+exTgNwv/74LGui7MaxNaNOsZ/M3ECFUI 56Xji7+h/Q6N6btUcTWNWmgGmHE5QNqr20Jz2pRuOPlgPfQa29mU2WuXc5oMoBjtdWinobHkBBMU kLOchg/WBSJgEhz/hd9UWdZAGYJn8ckyFXTR5u/P4vdX67pzHD8CvxNYCdJMYticMbfLJIf9RX06 je0Mh4cUiJkvRjUBVTeJ9bNQ0CAchqaNoeYZaBIYAdRYWhDJDuS+IHiye/yfBa8IlkyRxYA2f+0A PzE/JQuu8Vw6Bjc0zoWJEe5D24ZGzjOYjVF7ps2cgc/zLNFmh/EYvKjjmNFco/afAYfThJR4KKGC rPdIeo1q0T6l9tIoPGegSQCKW2GGde6RrBhZFzGxb5BGBf6zL/BJgSUdYBtMp1WEvzcDhKvkrAkk Gt6O45iWK6hPDc/Z7CCjemthgSUhMeVU5Av6K0TGgcj9GenzOOHOZJH8UpWPV6P2mAGI7nYksN5d EuevXIriVUa9TotCao9n0cBrNhVAyVluQyPo1UTBwg/TAXxM6sr8hNPRVJ1pfMdEruRQT0Bj4lfS SrSn0Upr6ZNqAU1F18AHW9thyDOZFNe5+9/xel5iMCJ1MhhPFxzoURRSTS4rZjpQu8di0qT6Zk51 408HS5JXGi8bC1JQGUAVn0MuPG/VYlWN71U7oxVnoKkAyneN/mnkCOsiWtn7BIDvboDnvMDBBEM2 6kD/14r3p3UdMgNzciwpRp/+JSPr77idKN0hEotKmz3j90tuUbKUOCJkf1mM5BYmSXqyFo3UposH 4Olz6eTLTWPUc7CaUfXTK/kVe2CQZVrkMCMwQVTHTUGjySsP7QW8y4X4fiT+fz4aGSf+hqgM9VvQ A+c4/M1kz8HfeWesx/QqjqmiR0Jfp+P7kwK3vg2ftKk0uV5Ya0xhUwGUxhxylbSmH1GdKjBxFPHf wA2/VsfA6wPg1rjn32SfBE+3z/Ci0Wye4ULdcJdbLyOSt8p1Y76G65JDXl15opSjNtKgLjskDvHw Gq/fxssEULPjUGf5fuswf+ljP8VZE4Vugr+28WhqvVzABZE2CRp3P0Wjym0g2q34jcXtJqMRQB8M /EYpE7W5Mq8BFrAY1Jlo9KahV01QzKGaoop0iePZz6VotKsQWO9AG4Dvb0I/YZPmpqkA+gNuhq5K 1+OGrsMNqSeO/8fig+I9y/OSogKftX2E6kjrOVSpCziRtYn49Z3/m/09Ozvb4DKPuN9sjTjVgWgj l0eP3JML5I8oQxEfg0eFZfzAlHeUHyjrnKsXuCk5LX+zM9wCNw4A/QzVPQ+i+icDGlB6GlFJps4e neumzMz7F2VlPRgu6qtzcLdUx12O954YwPc+6PcNlYPiOlfhN5XHFL/RbZEVZ+mxQwAl+PH3V+qZ tWz8fiOOUzYT9EOwZYb+7mh0jQwLahKA0pEdN8QdhLvMy/j/osDdUNhgad65aJ3QaitqRe6Uv58Z 8CcNTgYWStbK0JnB75wwsvxM69Uf7Tx8R86X5X9DfUjDYkLDcRA7rKOmG/TGi9xQeLq9Pjlj4GK5 ecIXKDcBGT6wl0ez9ATJn0dNo7acAfiVbNqTIrO3jFClj/lSIjDM/yB0Mn3ShU+QGyMItSsF3lV6 3ywNgicHhP9ztND5KKDjhwmfVnyPBabcD8lhBst5N2iFUR1Q7Wb5rrO/sJJamwSggUlbiEmiU/vN aEEtzY+48W/wPfWbNAhtquWJ0zWJuwldmkI1PChZeATRJapv4NtHAhPIv4Og3a6LKtwvPifHF4eo 6rv0Bkt0md0tw5K3y03jvpIoxruH2ok0jrN9HiXelILSaHlu8amSXxwvOljfu8UUIA7ep3TREVZr vEecZ2Fw7Q6gGEMsWiJaXdwjOVBPADw5pxTXmRDl+cAEU4c5HBjxb3xS/Ee5V3kNx6+r5wGciN8Z ZNOoQnut/VCbDKAcGG6au4vackIpoAx+p7bB43eK+HXpRitPDex0f27tiTha+/eK9SS9wTjF6XRK BCzrlwz5SeKRsk4rFBcGTxxQ40bt+LdWTpEfUVfebHDDfckjl6CYX7EjUp4FqKLQMd2Zhs/J88VP S9WR8WhPIjgS8IIquprGQrXcGADkZ/jktkxD8u1owZR8ZK5oWKILJLdwykD8u1ZCX2Pw47VofwUe HGjPCah+7WYBaDjdiDaWI2dgYWys0eetOF9n0CO7j0+O6b5ZpvSEaknzmQ+b5WKAspPZl+LgDbEf tZDOTZ8vMzMWy9r8HhKP7wvsRjHrdRleZwSMSfa57TxwcoyMNOxWxzhoA2FkIqVFcpuFAL3QDN1m fLcN36kIxfoI4NkDx7Bq7MdotTJl9fXTWr9rANpaMxsG/ZasKukmOvPxXijUKBKe1GelmCx4BzQA DYOngyFQxYnncvGwn1APqUAVlPvj6NnkOaVfwm7pGlUoexHYYLNYE1xO+2ic0d4AyiQ+FLU5ltqI mELQrE3FRh0odaSW+lyScAy512fR6AJ1T3U3p3B4iBqAhsNTaKUxII5lOIwQUcwtmRJ1UAazVAeF MM1I1Eoz3sRu8TyOS8uWyT3WIQs9pF7scVaURh6SuF3W7usBf1ATH9voz7MttpkZjoC1r4nXasZp ADA7QI15KV7FJ3NgvMTu8H8mDWJE4Tdo3J7NIUak6lekCE/1X53+nDifnO4/0Whw/j2OD0vvGw1A m7Ggwv1Un1cHANUbXS49OJp8ibdiDWrGovB7bNzQAJoKPIObGz4zsOFZN44Xl9dIAO1ltVYgzlbX bgAaAL55ALff4/9/wefMAGBSj/me/y7UCqvLT5P6zmE494vAuex2PRoztYXqQukqRZep1Wj/xvEU /UlfNMAFqs2esQagbTbV7XAhr2+o3mjQsTxEr077JArlIjQAbYfn0NBLVpMMkpDcmkYlB4r9GXy+ 7kZdFPyqG+M63dALN+44ANgPADSK8uQ8KdOU4jvlcYPv38DHB2i1cZj/xG/UZdK7hueSyF1WvzG6 Q7IeFHWqoa5LwVwajRt0Kx2tAWgrTWxYdKvTp6LWOwxIekmFa4xwDw+rQLiwmKWwHURSFAHUrWrE o7xHlwp3ZeLydh8zAHMPBsFWhQJcZK1W9fp+D3aG4+hx0N5eB/XOc7MBFDvO1bgKU8y9WV1Pgd+u wPeMjeXe+gN+p2tDnVRXfzWd2NrH1zfejvA7J19FFwX3+44w6N/6GPHQYlGfKgZVOgsrYkRnNOFd ddCoolEYzUCTATTgXvAQ7uVCtM1on6JVKnrx+134+zg05gGF7obcfWYsQLRG/8/6+qs+Z619fBg9 o6YPxUc/O78F3unGo9aMR02fy3Y4k4/LYghGO+Avgz6sonDaYUrC7pJNBlDcyeVoDK16Ao35QSsJ 4EY3ByYUuBOAOZc/4DuGdd6Az28C7H/1yai1v1pmrbWPD7uH1dgB+XS+XUyUrNcZwMVAfcZ3UbPC N3Ya2+d4PCePT4/nRlVhgDz66uGN7TM27aqVM9AcAH2MrggAxOvRW/V+JuE7KntDcxl+hb+ZXYVZ XIJRCaGPoq7+anpkrX18x18mPtmBnLyC6uKyr7wTMjAZxGSEl4nGiXaYZ0sQDZJR3JoGO8yeXJMB NMSPq6YSG71xnwz3Cn3gRfibbg416nHq6e+IaWvt48PsOTVpOMiutJVZzU0Gj37TgVQpskdKYif4 QmuuTE2azzpPUt6NIM5tS21QKpeIn5hcRFNht/xja26PTQbQei7MNHbV+65cC80dtHZ+w2YABtyf vUZfObKbR20sSJXth7r4AVSjlp0BrPSVu/pIGfKpTuoBl0aCaQtEex0ojxHkcKUFXrweVxniIdrV B7T6pEH65J16wcwcsWXgN2IA33kHfm9Q/s66+gu9NqOY8Dd9SnjtBvt1NbT/xiyO1gJQBvwzkiB0 0+T/2TT+pzFPqBnHRhcO21yUuHqlTq87xukyyMJdA2R0N4Qpa3rQZsxqtVMBIflF8Srxx/r93eTy 4T/IlSO+F7MZwlaV6l6Nv2ROYVdl/EMqA7Kg2/Cy1pl0o/FXaNoZgSih23D2RWi3oM0O9hRweL8C f1NdR8Bn2Ob9ALp5tV2trv6qASdX7ji0e9AIotE4dyE+WdyyViBtaP9NmY2WBNDQXYj6z+MDIBrM nsLSHhT3mWigIdRYQai1j2/ImMPqmAkTFjtn55g+xqo7hkXKvkGs9RkDF0n3eDySZr7cYXWj7TUY TCxF68/Wj5N5OwZJpMkhLy+fJgXgHG+e8CUCF4AfzeBEtyGdncuD0n9GRMd7ZOPuCmn3TEQAI6rn nkTrhcbaZp2qTf+V+PtitD+gMYb9BrRncN4FALkj0lU2oL/Q7olXtKG8jkbQHoL2LhqzwjE95hHU yP4bvZJaAkCDfhah4gUNRvQP5Q7FySOrz79/QVsT2BEuwf83YlK/rzbqI/rD8XxIfCitcnyjZ60D neAU54dmt+EPRpNlwG4kpnht5VT5y+SPVIRLi+nqOtB8tPhQIVcPR2mUCd02ypp9PQGoOvlg3SQk rjbIXZM/RrkUSK+NlbkCchvVLg6PSSKtzKal35z7wZ3lksEc5u1KlCx/QCNHyYxKlTaQwHvK3KXv 4L1W+T3x3Qv4YMjn2WjM0FSdau2v+oHok9jAPKJBWoD+v8QfyFRVKzW4/6bMapMBFAO/ERc8AY2c JdNbvYvvOGm4z6yN+D9zeD6ET3KiEWhMhMrCckxIwKSsd6J9gqYAtI7+7sXP1Ke01vEcb135DZsy r2Fzzsw03c7ZOZ4XDDrdk3qIgl9uGi2DOu+Us4ZB8uGL3ZJGj7C56zYaiDLs+GRCnw3SJ36PPDr/ LPl5W4banD7dOFb6J+TJBcOAM41VmeA57TiYKFuKkqD/xD7ncYvO41kfDmU98K6swuyuCvhh0zUx VPJLxd+slbYi+ARwfCGOJefJJMpG/F1F9qmnv4Y8SGJLrfJUC/Rf5xiaDKDolVwmU1bR0s4WjUYu VHGiGPiXAUBNCLymrPketGDk47spaKF6i9r6owKaIWOtdXxYKeYbsmIae4zTpn/VZHdMs1is0yvs OvnX0hmot+ORKb3Xqqqc6gWnqNlYJUhjB3K0Hg++KCm2SO6d/IFkuk0yf2c6fG+98tqqqYo7HcgK p41RmUBem7djsOQVJ4jFrBev277J4KxYHGZ2eGJH9RVDACWzU70mNvGBwTSHfbKOXAs19VfnigG+ MMpxPNpfG7C0Gt1/A/o8wlLekHPUMQDDrfhgq5VwTC5+ZKtCgV2I+pFKakB/rX18g++9ox04M9VR NCfHcLfHpRtgtZh6H0LZ3CcWnCkfQdQ8f/AvMip1syTHFPmFMXKkXP6NFTs72qS09HgxZwmdSuSG MV/JlsJk5PGMlT1Qmfx76SnyyAlvSGRDE7kAYpwVRlm2u6+qkhoHW7PHo/tlWoaOGYvCnbhyGrNV NPl+AJ6xOPlRNHK7nzW5o2ae2BwOtJmX1k5vyxmYluZZMSvHd6PX437eZNT1dIBTykauyQ0HzpcM lDIemrRVIsxOiTHZ5UQkXu4cCWFB40gb94gAH+ldd8llw36UJxaeoSxMC3YORLXNsXLRSJQ0asim hDdy1a5esnpPL4mweMXjclTo9XqW9u0IxEgpyjIUqxUB6CjfkCultNkMk9rh26cqAH89hkZL/K1g vhoys60yfxqAtsq0hmenbpt3vrFcnAaDEe8yYuTRaOxYlt9Xft3ZX+xui/TotB+Auk06RwNAW2S5 h+dctMqouOGg/S59kazY3Vu+zR2OmkcmfI6Qk/qulMT65hTcp91uVuWNGTkWbfOJ1+VdVWHxsjRw uBHDuKvn/qSqjSoxVhENui1RrM9AexFA5wkAqq4G0KupvyAAVx4fAM/70R8NR5egnypF5hrbf3Mn VQPQ5s5gBzrfaNf9GdxMP7fHhwJzFaqMRIG9kxy0R4kX1mNmbDJAd6eFvDTjoWLTibA55KIhP8uq vb1lX1msyipPjvKEOOQGrmtTgu7z19wB8v3WYWKDHymkBS/qWb04M9UeNkbOgAdNX8xQTzTmA83A d3RNZJ2jvfj///D/G/G5Fp9Uu7EYHHOFMk8oKRNtEn6/CMfvr6O/rfi9KOR4Ji2iuxL9T2lQ/hOa LaAHpdogF8czmVFD++d4m51bQAPQZrwrHenUOXkWWEd1M3XgPiucOug+l8j1476WnIJkWQgxkz6H JU6rJEJ074Q0apr43oynC1F+aPI2SYvfLfugCy13m2Xp7jQY7bJhoQ/JOh96CbyJ+4o6KTczOs/b rIg+cnm/c+6BnyP9XMKH0jAUOrLTIEQn9mFoLFv8FNoCgNILADWO9io0cqjkEK8P8XShAZnZ24K6 0tr6Y5KiX9GCx9OYTHVA0C2JXO7UwHfcYKgPpRdQQ/tX423utGoA2twZ7Cjnl8kMJGXq68SyTUax MoqU1ginZJh2SEbKjpCg68DSbjetUkeZ0DrGCTFeb/TJpO7rYQxKgwuST+bD0f6ijJ+le0INQQzg PEvsNnl60UxZva8XLO8Q3b2eEogEj8+cbGcZ4bAhAOFyDIY+nbUSQRQ/sh1B+O3F0C/r66/68Tj3 vnqu3aj+mzuxGoA2dwY7yPkeg36K0WSzlkDIGd5rqwxIzPNXriFQarrOln+KmNfjemXLm6uPk70Q 43fBJWnd/h7+KLBQv1CAJ7NkvbR0mszaPArZsqBGgcOu1+V+oZuj14/+ckEahesMaAAark+mBcf1 eXZ5jMli7U09p8XglPSEXWK2ghXVkqO14Cwf2VUySnLQD/SbLSNUUusNiCya5lmh/q9AFG+fo8Ik /11+orybPVmMKCpnMRvE5XB8FO3wPpSRsV7b2lr1CTW/cw1Amz+HYd+D0ZqYDFYzyY3iZNGIz06N Ptgwl5qwv7MwHiDFeADiwM67FICScg4mixOx7RYrlKQA0J0HOsuLy06WrxAdRvC0WpDx01Ux36jz 3jY5wxEWiUPCeIbDYmgagIbFY2jdQUAgTMH73NXjBYDaAKCdIEZqPp6tO+mcX4jnfRHiSaLT2M5D ncWEHIPUd36zaYS8t/YYgGoKpAKPmCwm+HxWLLUY9b+f2tNeJWikdQeq9d6cGdAAtDmz10HOhTou AgxPBPBTrEYXipXBp1kzErX+08Okx9tKVUUA/itCWZWnF52OtHfd4eLUC4lCzHCW9wBadeA8nR9b rN47p6ba64zua/1Ba1dozAxoANqY2eqgx+q9Xp8P6ek5fKreAv/toHfTsYbNxCI2pLmrgCuTE071 b6+ZojIsMcooGmGabrf7oOj0T+2zu5+6vK+jwcmBO9YsHL2j1QD06H22h+9Mb0TSNZ/iOYmiNCZp 1DYzwMAEi8EtdpdFOO0ms0msenKcrgNup+cn5Pl89pSB9p/aZjTaVVp6BjQAbekZDcP+vCb3IZ3L cAjeMVEsO0G3mpQ4zZDU6o9K8fz+stKB6C6feBwL3G7PYp1eP2t6P8d3rT4G7QKtOgMagLbq9IZH 526X7DL7fPlGoy61GJmYdhxKlBE9jkiSFR6DPZpGAY6T4nohivn5s8p7DlnEcdXUNA9DGzU6CmZA A9Cj4CHWdwvLTu+TP/6LbTuMBt2YQ/YI2VyAEGbNCl/ftDX/d8zxQXu0KgzHtEH4c68tLnq7SFHz +9Z6CIsZ0AA0LB5D6w4ia/1679c+a7bP4zrboDeo0hN7i2IlqRNe5DbJ3ti69xeWvQeSVG9jVnnl xIQvdLJj/+58vSRUZnsLy6Frg2r4DGgA2vC56tBH+jy+bzzivNFmtiSsO9AdKezSZEbc0g59T+E+ eLfHICv2sAYbSDlB6Fcs+2CUY2aGFp4Z7s+uoePTALShM9XBj4srtC0p7Fyx2GCQU+xOk3y4foJM 6L5B4qIQHK9xoS3/dJGrqNRuRcLqbqquEWu768U9PytrveaB2/Kz3W49agDablPftheeMKHIPTvX 8qzH7TrOZtLbVu7uIx+umyjXjkaycyYm017rln0gAE06yxdVRCA5CFLTuZ0FCExiGjeNjqIZ0AD0 KHqY9d3Kbaf2+eaJL3a8YzSZrjJ4XPL66uOla9RBOW1wQJTXQLS+KWzY7wBPNzIsfbFprKprFGEz IExTt6jC5mOuSo2OohnQAPQoepj13cp6GJPEHfmwRxwTLRbzwPIKnTy18HcqSubMQQvFYIKerro4 T+4UrJPiUI9mUT80tqC5Hgoozrdme09ZhSz0Oh3cl+C/hC4/Q3E/LUFIfYu0g/2uAWgHe2DNHe6M gWW5EOVRXM7zms1qSGV89j9QAC17f085d/B8GZwYSK7MeuQAzOw9PeWn7RnSM3afnNpvmehry6je 3IGFy/lBIG0qiLKqpsMkn6Cu0X7UNYq06sXjtq9FLNJsrVZKuDzklhuHBqAtN5cdpqfpfRzfz8rR 3wXP7n/YrOYUJ4xKn28cI4tQWK47MjWlJ+6ULpGHVBLgnwGezCI0NGmbTITRKSEK1ROOtiyViEn/ au1ombt1iCRHF8qY1Bw5tmd2431lCb7g1metG6VS2JmRlR5zLHqv752Z/XXYmTQ62mZAA9Cj7Yk2 8H5mpNnfmbXBstXrrfg/k8l8rElnRCVI1DJHmOeKPX1UcTmPj+InkjAjg9NaZFPfXthFEmKOQgBV Bp/e8unGcUi04lUqjWPTAKCsct4YThSi+/r87vLfFSeIy2uUCNQ18rhcC1z6ipc07rOBC7ODHaYB aAd7YC053BkDHb/OybGc6/W6LtHpvOfarMbxyAyEapAseoyE6V43UpC4AaQGmYZa8fExR6HLEw0+ doOqTGpi5iSjQ1JQrbRK2Y2GTDrAM3dfsjy+4EzZWdxZbBaEvTtdh3Q69z0z03SsJqnRUTgDGoAe hQ+1Mbc0Lc2xD8c/+XmO7wOzxzpGrzcOAWoOAIIYfD7fCXq9IcHhMkjniGLpHrW/8cDSmMG0x7HQ WRaWRkkR4tWxiaiM/d1jAnWL6hsPRfaA2L5xTzf5+y9nox58H4lEjk+kvBKfwfvwKX1cc+vrRvu9 486ABqAd99m16MjBJSELuoPt48+zLTYUzNYnWvXXAQkeR6UJON5PRH2fXDlp4Eq/WNsY0bYhI1WJ StHaWr+Ka+5B6eHdpXFiRmZ4J0Rv6n7tdovK46kAkmMK3m8QNAO+s2Vwlv900zh5Z/VkyS9JUHk+ aX/zepyP9HD2fVIrCteQh99xj9EAtOM+u1Yb+cwMh52dv5Zt+XeSVT/TaDRMLq/wyasrT5AhSdsl OQ7wSv1gSxABCUYcFrgrKImReHC6bZqtFECYVxIvewGiZoNLPF69vLLiJFm5t4+c3n+JpCXkS5eI QwBTlDCFgYieCaUOm+SXxcuq3b3lx21DZCnCYj3QFdss6Awxs8g58NCvb/0185SsrJbeZlpixrU+ WnAGNABtwck82rq6PMNR9t0m24Mur/tTi1kfuRFhiU/MP1PumfyhxEYX+31DmwMRQEq70yxLd/ST edvTZU9JnPzt+LekUwRKobeFUz/wzlVhUAYkpp2LMlRABWwAF2qWn7cNlgU70qVX3F5Ji9stCbYS ZUwrcdrkQHmMrN3XQ3GtLAZngmuXxWSE7tiZh4Luj982s/ez0/tp4Hm0vQ813Y8GoL+Fp9yIe8wc uWSIuEx9wW1ZRe9akSVjvpuzPuoZMclfzQC873ZkyKH1JXJsxmKxoUTyAF2ZZBgApk0hcHT7yzrJ /807SzahuFqM2S4LdqbLKenL2gZAeX1kpSJQWo0qSsAD2TsPt9mD3KQXXgi5RamysaA7OFN/TiX4 JagaRxYUh4tEpnnGuXvBdXrc8o7B534COuXlCFhQs4G57I25HCwGT4x4DDlZa4Yvrj5NOKY7jhnl n2/ZJkb70qzFE47mkIWmrJSwPUcD0LB9NC07sMyxC1Ez1xgtdht4xg+Ks9ZnVeHxMoesnAaHxb+g 6MQA0fuiaUQSr+lg5ujln0V1S/jPkO8Gphb2PXTJzj679CsRmvhm+TDEeHslBoaX4YYiud2yWU4w wsjUGMIIOkcVK7XADliuKQbPyhklJ6WtFNYSahZ3W984qCfATKxEvDqt5hYzjD4eKQQLei64yFSv uG7CHAwx6XwxZpPerJDSjdJSHp3dY/J6keXf6NT5HJiCTyNKza9OzSitLMuBucTk+O4RnRl+UZ5Y 8emN2IBKMoevXACQfCxr+fBfAZzjxGf+o3iMxwM84+EvBjjXl4rDmp85evVzkpb6eta7CS2lKKlv NrTfmzgDGoA2ceI6ymmZ6dnxYnQfLy7rVADGKDE7wUidMT9z5LKfxG5ZkLU+owAv/K1ilPshh8ap cE1wWwpdTD5kwjDcUJp4IH3xWYu3eY0el8/ssYhbL3Y3UgQD40ohwuZ7bfKzO0EetK2XWyxbgL8N lOtZLjTaITMHLEK002AVN76pIAXicXcZ1m1by+lZa3pYuMXiMpt8hKxULLKnh/uWR+f7eUZameIS Fy6M/aIkriTNazSPRyqQfjqHUZyRjsSipKJhhSlFlpLY4hiX1eUEkFokytPvJ2/F1qwFk3cAGH8n PtOT8KLvo9QQUAn4P70RYtadiYkbBCB9G8B5mdj0fXFRADPNTkzZhPm26ruIy/OyrNsxNjN99x14 PvAd0yhcZ0AD0HB9Mi0wrsyRKyeArctEVbOTlTmZEdkko248uKw7xOL6OnP4ipXAyrvAThqlDG+6 3ieDoN90wpiSUwJGlKGbJuNUTwTQ0o3/V5jAm3pkaPwBJdKuLuqkALdUb5K7yodIJ1iXrrJs91+n NhwNWtyhgywqjpTV0EGaIQ470QczuC/O6yfDUgGgARxvgak4sgvg2pdI9rEGHKjBAO7T6/bovYZX gwcyexX+vwFaWjSI46fOQRbquL9hQjLApUZU5gUw6AeI23SB2E1rM4cu+wTAeC3k+ySxY65w/72j SyUGutPsYkjxTlzUpBuAuc5Sz6Icx3j0koqUgim2Cll1KEacZXAopa7Epv89LFauzPT0m5kQu1Xm QOu02TOgAWizpzA8O8gcvuxkiI4vSqSph5QD/PjC+isbI1gbLyjdcCyGU6DAO0X9ViHSK7pM7huw QSbGH0QkjU7ezusuT+X0FfqBKjTwGKUnXvZHB6+V0bGwxAPh5hUkyMOb+ssWAgTStj1S0V8mGQtk gBGME69RnQJDOFgaLb/mDZDP1o+VFbB4sy+z0YPqlSb5GC5TE7ptlIxURD+2hhCLVZ9XGC+fAUDd XoNEGk0+r7P83fnv3DXrwawHjxgyuMqRktf5VYkwDVXASGgNziW5Rye+s+gHI1HAYEwcMNcHfa5T /tJvk8xI3qt0pbP3Jcn96wZJIYxm0Ikq4IwwueTuQZvk5C57JdHilLXwQnhic5r8sLeLv3+D749i eecHkeEfh+cq00alAWgHXQOZvZfESZykQ095jHhgQvbTejF5fxa7dBWf8XG8oT2k1KPCMqd13Sdn JOcrPeNHu1Pk532QFOGaRI6THGSkxSUvDF8h0xLpV++nv0Rskv/u6Cn7SvHSgxONszrkX0NXyanJ eyqPSYssla7WCrls2SjZb7fJFmOUXJ8/Ra46WK4SkPSK3aus1/S1ZEE7Go0InBsPpKron6KKSLGZ vWDKfLBi+2DMccKfMh4uUydKVtzbEgXOrEWzQAHUvQC9/y0/QXL2dROryStOU1nh7vSdm3VXnXyd 2COHQ+Qmc70KKop54L6LxGt4WCLMQ6UMyIm5Gte5QM7rmicxAMC5BYny2e5kuDbhEQTm0ghMfWjQ ermp95bKebqxd658srur/JCXqnyhTEavPD1ktVzTM8Ct48ietnIZgFwDFy4ZI0sKOotEQQ9d7rkT apg5migfni+qBqDh+VxqHVXmxHkxUhJ9vhiMv8cLPgxcngkyqP94hF6LV5+LCmZFQKQhBE8buJ/H wTFe22urmCmOg67ptV3uWZ8uj69LD7z0BrmyT24V8FQHAltP7LxPZruT5WCFVf7af0MV8AwOcjo4 qKt7bZN/bBgIrPNAHxovB9eOl+gSK+woLlUTKBhXz08nOFkvBm4G0sREMlemy+72et4Htu0C4/Vn Gww0P0Mn+vqKqfKHsbNxexR1W+BBBVLzvbniOPli3QQRbAj7u++XXQN2RVfElv1FyiOs2G38qgNE EgEQS8TryoXIPkzKGF2kkzv6b5L7B2xUYjnpqp475H2A4kXYQHzkLnHy1NRdcnWPbUcM+KTE/bIV UU9bwa3f2GdTFfAMHtw3okzu6rdZrizuJGXgxtFdhlgc4/G7VgK5BZZAS3ehAWhLz2gr9qdcXsqi nhKb7myI57QKA1iCBghcWA9LrsHXTw0BvxFWb+m7RW7oc5gT4k8mcKQ39MqVXeAYP8tPpRuOnJ68 +4iRdwKH9daopfL13iRZXBQnV3RHoFItdC0A451d3WQ7RHNPpxIpiSuViIIY2EcMGCpKqsGKTSAl OFmtBkioSE3qdu50O/WLdW7nR6cOdL3Drr/ebBtkMpvP9FY45dVVJ4Dxq5ArRkKKbW7W/AB4fr1+ lPxvyclSHuWQ/BE5UtCdYZs+k3iNaJzTgOIVelHMZTTGOww+TAo8z8f9/33QWszfYeUu3ZpmYu4e gOrjtW29ZQeqnnJDiaCYXo0o0vO3H8FdnlHDfAcPn5G0VyZ13i9zdnejLjRaKnynawDaii9WM7rW ALQZk9eWpwI8e0Bcf1mijCcpbgjSpAFi4LjOB6Wb1S7lbqMsLIyTAnCK/lAewBVcgcbHHaxxmD0j 7PLCsJXgTLcBQCGW1nIcTz4FLzRbXdQnslzS0LaDu/JBJM8bsg1aBHdJ0tauEcDKQp3euxemGlig 9Hav2z0fOYYXQlpft7/EnH3xhFKE+fjJYHbe7nHpk8wW88QKh1teWDZdcayXDJuLzO44jPrHBhr5 VYdBgxUw8M1lU+S1pSfLfotOdo7bIIdSAJ6YN3EZ4YDgkkldCpT+txDp/eYd7Ow3kNE6TvDFZ3+o K0LBMzhmgiW50jO67pa9DosMj6ndL3Z4p0PCVhdRZzoUfczJ5waJI036S2Hs80El87esBRlaYpK2 fPHquZYGoGH0MGobSuap2TbJg04zynSSlAJB8FLNSMlXot7g6BJwO24YQ/Sy22GV57f2ludz4R0D UDCa3XIIn7VRNJzHj08AiLQQdYMOT3FxED0rYu2SO2ar9UCP/W+n/zrob4iSLK+QCr3VanVH77Dt D1i5cWXEcIbQtJ6ebbM2VNwI4Puv1WoZ7nDo5MXlJ8OZPVWuGz1b0jqDU+YtEVjqsk0TOAO2rwMw zvwPYagfZB8jLnDC+0duBHgChzg3qJw5NWmP3AsAHAbQiofxxw2w3Acg/Bw6y/s2pMsBiN16AGyk 39m+ViLotRSl2hBNC0kBUwYu1BcHtcwtUuJOhT70WuhDi1rqOlo/zZsBDUCbNn+hPFBLaOfqHsU2 B3wGjecpIwZEzN/3zYVecw30cCEvNLggitxPZayRRIDAS1v6yh/SNssF3fKadodNOOsyiLi0Mv8C yzx1pmLzmop7HDppUd+572T9MuFrPzsIwEytCprVLzVjoGfFrO3u62DdftZqsox2Qh3x49ahYFd7 yGkDlsjJfVcoA5XJGnC2DwXSIMcJFeWuwgT5BbrUj9ePl5yDXeHW6pPyXvtkby9w0/BlJfd5To8d 8h9w4gmYsyAZIaKnwDD2x95bpU9kmdy6aricig3rZuiJ24pomb8Bz++H/V1kfTHcycgJW3TniM61 FmN4oIXGoblHNXMiNQBt2gSGOtd0zszMPAvdINOwUF7Oz8rKOlKh2LTrMBwwBVzSTXCRUe4xx8MC /vf0tVXBM6Rvhhn+mbo2iNwZ0YcqDUdNvHyjTpsKvR0bXXZuWDVMcsH5SbQxWYrlQXBOK8E5NXhe ZvRErtJsywVuiyPLYNBdbEBKqAMokfHSsmkya/MoGZOyWQbE5yNWfZ8kItkHzeYkOuNvP9QFgJms knysP9BdJUm2YqV7zR7J75cH5TAUmuA+h8cXyDOwhIeCZ/UbntZln3w16ReJw+Zkq0Gv2agJasTB 6XAXe27oatlWHiE3rRkqX0K/LBHKFe0G+Pd+g2imhQ3tDuuT73l/tFg0+Egp3rwIDchcSa3hMNbQ IXbY4zQAbcSjw0LsicPPRLss5LQ0/J8GkDI0Krf247iV+PwcbTbAtHlxzV7TTDhWDxYH3IhsDhgx 1ikxsy6itX2M8tNsH6KhJHPgevnjipFiL8e7GmEajTTvl2M0jzZmRNMyHFs+L0+/1py/bQlk7T+b Tcau8NiUfciE9NG6SYh+FEmKKpJ4W6nKnE/fyQqXBW5QcUgOYoaLEkAP+lgdjFj4Yu++7nmbSzoX j4FbkoW1nR5I36BcsOqj3kxu0k7UC9d+esga2QI1wnrE7UPM6AxJ5I7M9HmXZ62fzDVXK4Ws1+k4 qBcaATMejQDKDT8y5OSB7XSLHfqyGoA24PFhISbjsNvQzkMjiPrZHT/RxED/Fba4wEIdEzh2Lc59 Gv//FEBaN+rVMI7MCwpMss53rj+KSCdn9syHsaf9gLEBU1V5yIVw5flsT1f5mJwTFR5emQ4u9CWG jjamn5kR6+2SJk/P2WD4xqOzXeHzuS8z6fVdzBEw7yP8ssTdSYoOxR5+GABRK7QHEfDA97pdPp/X Bz9O/SeRB23/2Dpqy11QZk6kXvHklDw5AW5FHYH6wLXpdui7b0KIfYVylZKJYowehE9sLEdSPes1 eAKBNJT+iPMm4otnmrpeO8JctvQYNQCtZ0axqMhx3oc2osqhZmzinRAPbsMUEk4ZgVIOKaioUr8H Ey4WushYtDfQzyMA0ZxGPcDcnfC61sGxG1mAwDGdj5e+o5AJTuXXwff0yz3JqkoleJ5hcCDvivE3 CkCD9zttoAchlaV/+WGD4cUKs3GGzuU7FpPSx+DzJkNtAVShb5FiQ5EaSb/X7fPmYGf71SKWOT+9 ccsagDgq5/1uFCza5EflTFjMo2B86yg0E4auxyL7yeZi3KrV0FVcLjjxHgmgzViv5E4noY1r8nrt KJPZguPUALSOycRivBM/P4ymtn1FKZB6hkGNNCRRJBn/J4hSILLDoFEIcTCnCEXBwdmsREQPQdVv M74SbRT6uxogurTBz88pqFHkQ4ykSD8UcxsIvVhHolGxRZJkccjOcgCoRR8LVwFyTdnNuYepAz2w 5HieQx/PfZ5noSMBwycjAKY+o5dZUPRum9W7bnKqI+BeYJepWVmSOTt7tPhcSXSDSgRHR++FjkRd MI8D8Pw3H8K+zM3b6R0Ojv4tcPSVRsx2X68daUJbaKwagNYykViMd1QBTxMW7TRI76f0FumDRcy/ CZCMWCGRremN78dA2ucxSxHu+NEmP6D6aSja6+j3coBojaLXEUPRQ12AKEfGTQ9CiF9cPbrPFloT LdYN0W08/Cp3lkUFfDe9YzLvv/+DrAcfbIwnZ63jmZnqIAr+2qABOx3d4RgbTet7j6hySaXLVQej cdBrfwXXKp9LhUr1h8IIE6v07hIW67WDzWdLDFcD0BpmEYvxdnz9dzR/jHk3SDdXD/GDoxGCoROb vrMGo6Wf4/SL9VN7iAxKEPkCUUAfbw4CLcWuV9D/xQDRNfU+QI83BSGZOnJNNHbU54dYb39tfAA9 AlIsIUYaA2onq50mq41Hgst5DPGwvtvIzSegPEddlve2H1zDrhjLsFiocnwUanw6t/TByligwDM8 1mvDbuOoOkoD0GqPE4vxhMAb7gfP7gDPG6H+HAmxvQJvX0UD9GZM+8bwv6QI2OshtUaiq3egwiPw QvhHexzXORsgWqcVFdxnBEJfFPdGF5qakhuF82pkhFMZirQdNrnpCrMebKdSFzpPV+TmVJuREfpZ +np2NCpCgALnVM2nToqz3swowzo6NmzWa0eb0BYYrwagIZOIxUgfuUfQKBqBVYE593qA53B8XY43 rzHvHI8l4JJjPQcueA78/4ONwZycyM8pt+B6j9Xm5oSku2eB+5wYVBGUuSHJ4+UhV9dhCEMtx7hD qM2VuEi+EiElETcjI8kV/nH4hEB0CM0KvWJHojKEtPrtZBi1xViU+c+/0yhHSand12tHmseWHKsG oFVn82b8Sas5CKv0YnCPivNsJHiG9klu1BQA0U1wQVpeGVNOAxWic2RF6OF44a1SFn0vkPJ2eIDb 6P9JK/zGsmg55DZJPKtDdhCqQG4TJhKu3Hn00qZ+Qwo8SyOQfMWE5MR4nhWcS5Gt5ZFI+mFTBq6O QgwUWK6SV2MtMWOUUb8LRsurMX56erTbeu0o89da49QANDCz4AbpEH9J5UQfD//F46HHpF6zuUwf +6AYT3F+axGs9erFpc/ohdUBFNzSnXCcvwfgqSKPTMhXGW8uk+7QgTLzT0eiD5DmTQFo0GvW61Hl ktuMSqP+hFCs36usVS6fxMII1wuhmb9DJqR+sfU70LfZOBtwoZ8PJMgSJItR3lo0XG4rGgs9xFB1 b6T2Wq8NGPvRfIgGoIef7hn4LxATlGATOR14GonpoegeShTJIwCGLojk9hr0oRaIrGxB4jEEULa0 WD8o06jkp4sB3P+BGK+CrBGiNxKx7nD2JniKZMQVya2Iez+7a75KGBLM51l9Qe4FU8tCkEwLOmyY SAyZvgCVQmheGuI41QlMzIgQj9aiIpFVq7BHVMPmZNjLBtYQm7IBqtw9h/MpSw/cTp8+R74iBxBS +STi8b3MdqRi9jFvPv15cL35JNT1prVeLswlIo7kj2ouHT6ZDKf5ZxDRMxDlSqwwxGzFjK/cgUdM rzTMmfmwo5rsRsDpRmhbgpQKb9x+/iSBivLgjru58hEe/j4NS6Yb9t3aaPVqxPoy2BfUFcJ3f2h2 WKuuPuJcPpWbBoYT65K+qxRCok2nSnKUWXbBEaH6emXcKl2dQjdcrkNmzg9ej1ws13Hwb5VJP2Q9 N2C91jfu38LvGoDiKQPE4NSpQjT9y2ks0CMdgRrUYYaSASCwB3afebv8LkvUjfINIPrwTIJrNtwP FwcQBnkvlTWe/qLsy4zpPhZv2HfbUdFMieIpaGegPaku4/HehaDtGILnAKQ8e3f0Uvgr1p/hZ9Ys JPa9yj+UX36BTBcQ6hbAQvskev7oo8M3QZD973/BaoPXZnj9N9+IXHDBkUu9Jzy2brwRyZevQQB1 rB8033sPWSweQKxA0eHjB4Gp5jVOplY3hP6zrZesQVIRVb4iYPXAf05CI8RgAlqZ3L6LwfUnSalP BsYckpdHrFDp6IL0zLMi//wnHmNvPM55yG8CkCR9+SWU4NCCLwyJNO/eHZEQb4hMmeI/5j//Qcb5 h44c/xjEn90MJRDn01jtzSLgnnaayM5AStWLLhJ59dWqwF3bjGwpi5T5BViPys0VjQbKWMRb9cRO SQCld0hwvXIdUk20AUitVE9YmwRUbtz0Yaa/MlVKhyAFcSNnJkEuhAw8q1Hohyoncrhs9a3XVn6E HaF7DUD9T2kk2nD1vyjsyhOAa1yoQR9Pfs+/uTiXAEneXIcFiwXXCyDaBZZ2Wte5CFdBxfctsKEX FjYX6fx8/3fXwPDeN9bPhfbAbwTo78D++OlYtCczJ2Z3lVIUewsA8k1IgtwQ8GQHwZc1AkPhMEjb ton8/vcia5G753e/EznrLP/3BIiXX/a/5OS6SgL+5NFwNvjTnzA8vGcEFB5z113AeeD3gw/6Oa6/ /Q3xrLfh9nqJbIF31lNPiazDVFx8sb/f8eODtyRyHNLkMdPRx4hEYn11FLHjj9FicU/GZ6sCKOYS 6dwh3qoH5pHzUvOqgCcHYgoUQWHYZ5AL5IZDYOOcXHfd4fv517+qAii5ehI3Gc5ZFEw4b7/t34wu vdT/DNhPKHHTIngOGODnbkM53qpHHvnX8E5F8t+Ry+VvyPi/CpnqWfBPrU26yTFoYxzYWRVfBeLN cA1m4/tT+zJqyb8OVyCw4w4gfFeA6AHs0PRR5jPphvW4/ZDIvyGGnAnmYBp2lCBTUMd6rW/Mv5Xf NQD1P2kKq4AfUBcssMFYmLSahxIXaAEW3mLId+fjcEYaLcNOf0ov/3vKxcjFeSF+I1gSQMdiYd85 F4gEma8/OAg3OIIYRC4RfA8DaD9wwDb5/txRkHLjKZ51QQIJRvE0lrjug2Awe7YfPCmKk6Mip0g6 5xw/NxkEkCDgUpTly09QOPtskVyIuD/8IPLhhyI33IAdBlvMr3BZp5gapF1gxAkMBQjOrA6gxyQU yAjcwzVITPzwxv4yb38SUAMV3Fxehgq+2dh7a9TxJfZ0xLz3p+jeCYaimpJKB+eJn8E5ePddP3iO hRnx//4PaM/gRtApp2A5hNibgsdzbgm07GPCBP9x3Fg++MA/z0GQJGCyb24wnL9Q9UBD7ssClcPp COUcg/kkZ5+F4nTKKNYDA6SPMoE0dL1SEhqA9ca1yPVGSem++SLfA1j5HUH1BOyU3QGecfidDMAj eLif5mCQYB7isKuoagdY0zWv1wSonfDUNfrNAyjAi9qv4ZVLoTcWlS2g4wxdHwTJjRCL9gNErwQw boFFfQnA9HjId1yw5Ag6Q0dFoC0BClLHFIuFyO+44yslI7laLMpULPpYLFx/3DxdUTLgstQf/cRI hU4GxZUgu3vdLqL1Ld0dAQaXHJYrxOefXGpNOksOi6I5AZRgOmqUH0CpsyNQ8u9Q8OT1qTsMUk2l 4CMhvp+cuFdWFsXIPETQqHRsdP9ubfKimJ5BUgkCyag7P6yeDPDB4ZBrJ1Wfs0QqeGog7oecnwTg F3WknB8CKHWohVgeSdgzeMxLL/m5z8cfF/npp6bffDKCElhXKYvriBPeGQ8zLc4fuKHUSEEuFNeg KM51yK8owkegUaRnBVbq6PvE+o8hUxCNtdgT0tRyMAXM5xCPRROkmtcrVoPMafqdHD1n/uYBFI8S K0el+vKDXz8syOpoEFiXSnynyE4OciDa11tF9mEBdocMRwDl4gzWXmdfBxAuSIv7sbiEErHwO8Wi VBxPzsEPoLgg8g2Z9WaCJzmLJBQ769zMsM3hw/1GJYLC1Vf7uUtylnUZOYKcFQcVNBRRPK0NQIIg zeOpJ6yNlLsQK1YiexImiPfbumQKpAfFXBrBvdVUn6imAYwejcCxL0R+/lnkiisgAZ/qnzduOrVR cM7KsN8dgPpbPVDcYfCcJQjafeEFP4d6/PHNA1D2zWg0MwxJTjDzahMegItx7QXXKA/iXs1NHTYm iUbbAgmoFMA4uLP/expAPQEJi3p9cqDbIMYnYeckx6m0LQGqeb3SpKYBKKe5dVdyh+idHCjYTs4G VmFi4G3hIgwS35KDFf64dhqFuFhHQCwigFIHRVEqlPg7F+aPYDsoLk2CWBR0hyLAcuGzHabOkPcK xY1rIEubHbHvLrz8NdXfqW9Gg9hPow5f/v/9D5qGZf72JgTnk2DGueceP5dZnYJgQEMUVQAkip3U i1YnWu4pqpL6g/OaTM1mLaQSEavMR2q5YUJamVBeHoDtwHOyUF9YAk+AWOQGrY386lkIFlf6uW5y iQRSNqowZs4UuemmI88mwxcsiPr++1A7ZvuPobGJ4j8x6sUXgV3QmV54IRg7SNWhqoCmzAK9mBjO yVIkSsoJXa9BECWHSUPSQ7CEETA3gh3uiQENBSvNdR26tsmdrgXyU1dP1VQMXgdypkGqeb3iTjTi DGgACgEI8+DnivhG0F+zOpmxCBdCEU+OcRgWIV1EKALRfYR6UCYZCbXGUwUwFzL0d9tgrcGiTAEb F9RRkVugoYoi1WFKkGjDZkGydHJqu+Gushf1jVgsrqlEd6Wnn/Zb5DMz/aIm3ZnYcqDqeuYZv340 SNRjEnSptyP3aceljznGf2514m8PPCBCDpQ5VW6+FczN4NpHWkpXJra2i6KimacMVTUtB1DbaF1p jHRnjaF6iFw0PQ2ee84vdtM97Lvv/KBKEZyWd85PUFJeswaYBFMVN56t2Est2BPPP9+vFyVxrmlc ojRAIx7PC4J1TUOhgagEmfKpP66N7NgQHCx3rDh6dFh1HflPIwB2wdrkZs/1TB3oV1Bqv7seSJ5+ WOVEoN0L1vll3Ahd7I7DBFQH2JrXqwaggQekASh4RMwF5HEQxWyCWygpn0xwTzQaUYfEaKK9EM2V yI6FSrcl6kaZ3o6iEMGVx76CRTkZHjvTewfT2h3ulX3SB+8wxUiPuNWyoaAQhXvispGybCVacwCU XdMf9Npr/dzPV1/5jUn0RSTnSGC99dYQtRmGRK7JhveOIvtll/ldmAgKoUQAuPde2Bs+9TPiEWf0 lL3TIsXp2wj//4BYWO3tLwmGIPrdvQhurUsm4wZU1dsgVt3EwmIbcpImKV1sQ4h6S3ob/PnPfnel f//bb1Cj/pIbzAknHO6F3CfnmF4Q5NTvvttvSOLf1Dtzk3JCDUkjXHCzon6VxM9QSzwDDi5cMgY1 pSzy8silcmotVVDzUDa5kiiWB305Q7lKrk3qMWmdJ4fJB0W3uY9gzaIbHTd/cq/87mUsiDL0cxvU muQ+qxtPebEj1yuZDo0wAxqA+jU+h+W7UNclLhFa0zcDNHOL/Nb5LfjkDs9FRSsm/6bynSI9kw3R uPQPKL6Y8u4ysGUqe1OoUimw7qpex5z1WMyazGGyCU9knN1ulvcRxTMDpTH0LcC1UY9Jzmgc7N/U xZHDpKFDvRtUS4JoCPnsM79zd11EUKHfJ8k3KkUOnT9MHtmMasW4n3v7bzhC7cBSG9tR10dlQuG8 +XTbW/vNy1qesSdz2PK5YPcmUmHwKebyNNSSOjkRz6mBxDm7806/oYy6UAIiHehJQQ6UXDfFfW46 1YluX99+65/f5cv9Ll/cfIJBDVSpEGAvPA8bV7JR7libIevpNwvx/LqVI+TT8b/KSLgvVac1rDOl EBEguQd7Ea3owb9DD+b6UmCIY6lGIqDyT/qBEjz52ysAz5UQ3e/DoqBPKRmFQNdHXLjqeg2F6wbO 6NF5mAagsDvi0VL9n6C4Sla+DJJ6U9CoH+IufS3eJjocB5OE8LvdWMTkOAuxm5NDfWaFXxl/00i/ tTMY3RHqp0cgOVwKnVfzm9x1vi+Umw8YgQ9QCqMvLPG39d2CAnK16+8asyyp9wy+7DR0kII6U35W QAVbF9GN6f77/Uec9ju9HLy+lyzQW8SD8x7LHajqMJ0Gd5tQ2o8SFL8ehMRnwD3TNUbngQKhDcjg eRea0MvAgXXbBQD/A+ozXdVzm8xEGOegTuXYmBo2p+TKg3PETSZ0zgiIVGfUBKCHDvmP5THkYqsT jUtso0fQf92Hce2RJQcTVFXTnSXR8vCmAfK/EctQk+/wenRAfP9qL1hkEjXJ3LzpMkevjlDmn3pL 6ty5zqwEWiyvudBB9AFIUhfK/fx9cKMLoJa6BZxnBoxLtNiTlC9cyGj595HrtaQNnmCHuIQGoH7u 0y9WcuEVhaAId+pCvCEU06dAP8T0dDQm8TguMnKXp8Er5z0sxjysqXx0w8gQWtmfAdsRFIcSwaKc R10oEIznMjyUnMBhAtsK0lteEY/zFPQ7qcJlkAc3pstHu1PgurJPbkB5DJbYrY+CRo077vAfSWf4 IJf5xBN+XR31o+RGSaE6uZpckYLX2w6+kVE21JVmZEA3erdPnD3WyeXzjZKDF74Cxq8H1g2QCfGF yLepvAsUrQbHpGK4jQpAnfiEiar1KWv5mDWZQ1beDSB5ERuSdXtppGTCf/JF+FE+M3adRBqgwA0Q 54xASCMSVRvByCwafP7xD78rEsNaed+k0Hmqbc7Iuf74Y1UXMhqVqEel+oOGKeqX6ViPLUhu6J2r 9pfbUYGTGT8/zUuROak75WyUUw4Sy0VnHwIAUv/JdUT9eyR226FYjEHvDx7MLGLr8aAeWeSXlLix E2iZFYyudVuB7oyWo/sTne5nQUdBnpJrmsnAJ8Loyf6C3x25XqGz0ogzoAGon/vzy3bUaVK/SeJi Ujs4pugWcJNKlxSyULm4+PvEVIjv4Aoo6hM4X4KijP0EkyuzLwIxXUqCmZnycA36k/qJSKoWpBI9 hy97BIv3S3AYOi8Kya1BEomd5TZhTZzaADTIOdLaG/T5JFf08MOHxe3gxehQz2ii447zfxM8l8BI oKiNPvnEzzGRaG0eM44TUIRGPMT/Ea66LGuifJLeTa5J3lLZzQvbesMaDYQy4xivrBZrBUwrbUaL 8Czs0EtbFejAQEMdoh7DKQ/sRfTX5CZCEOX933KLv4US1R6oCqJ8ZEl0WSLRb7Y2oxDdmGoyrAW9 H/g7gxNC6bpe22QOSkLPgs+sF9zmf3f0lNPBmTIHggthnP/M7Yuqo9CdR1IvAKkoF0BIlzoS12tQ zD4XqDwzLZh/1v8bS89wDRNM6ZucNcn/3LjJ81EGiTrVIHjyO3qm1LJe2+wphvGFNAD1c5/Ygv3r ScUQh2Z44A5OXzr+Vl0/qnbowO8ETRXWEir/BJ68Opf6P3zSbE1OlRyrn/AmAFhAmfdn6uTzMwdh 0SLxr9IXKncVC8TfGFPt6EYrL91saPBJAfNAoiGEImdo1EtQrxdqfedLzHP5W+j31dcsE5CQAyXH xVsJgq0JNdcXFcbKEh+MExjA53ldKgH00z0p8kU+DBmGADcj3heyFkwO7FBt8FbofJcCGTsxiXIS PBoSoyFsAEiT9eUyGcagUtwH75lgRoPOK6/4OUJuJkGiCxe5+GDkFr8PeivQal+Xj2j1O+S8zZjh d2eiBECONCgx8FgC5fW9t8osVDPlYpkPkZ5p9xhU8a+tfeQ7hMUq0Z3r8CeI5Ixnp26+ekYSqo7I XYYSz/En9PZv9paAcemIQfIBhyBqHeu1DZ5g2F/iNw+gTGiMaKQVlU+KwMbicHQoJiiSQsWj6o+U iBJMKabQJXQ7r34wAJE/U8w/nPmG5pxV6sgPzo0Uk+sqZC3CNXVyYfcdKCRXpmoh9UIhtNqISSzY QonvFDnN+ojW49AY9tqOp29jMJlG9WPeK4mXC3/NEF+pR9YejJKDLrNsLYuAOJohDrovRWIwdvdy cVk+r288Lfq7XnciitnBEVQnl6ftkKt7bBcmJe5tLpXY0yGtooUSVRvk2uujM89E2DhaYykYI189 Tj60n6FIfNIfCWQ2oQZ8BfyBfzrQWb7emywPrB+EdKYAxmisjcW7yxHfTii1SB424+rrNZgMpLYB cg0G13adN1HPem3sBByFx//mATTwTOEgpzjBRBXaRsdi6jztAQBtqQdPcYg6VvZ/mNYAxP3yvM2O CpzGbgRZM3SGd6TlNCkmvqWG29B+BngLUP2uQLZ5YjFl1N0OkG9g7NhaCraWFmqnpxzc9N+Qxq7h ZvCGXryW41Qy5bKoSMXF6z1qHvt3gKqmrNU0HKGnBFBWIHhk8wDZARWOm65g0bgXHaSV+fkvwwgJ vli6t+t6beYzOhpO1wDU/xTXosGxRKYrA89Pu/yJQBhN1KCduoFLgUYnukQtqeKT+H3l2XZ4AjAu CgBKrjMmxALbwCu0y2EpSPbMhM/bin2yp8IqT2+B/o2p16y4X58PNhFPZtaaUZ+26eAqrLSfo4gQ NTBOiasjEqlNx1XPxRi1pUJfAZ5utNwSbEJ0ASN4lrm3I4LtVhh9qHiGMgAA2p7rNZwmrp3GogEo Jh4c4CGI8Z/hv9CMoRInU38xFI6O8GUtxIUSjB0A5x9g/WUssp/WocHFPUBGE5xJfUa+PLFwXTIx ZK8DUCzKjLBiJMetFBgqogv36/IeBBv1cNbKUU+2+W0YsRl59DYOiPHw1NV2BFL2nlC3NSu+oRGy zD0X4bB/yvppxBJatMJivXaECW3lMWoAeniCEc0sv0cboTLSMLUXLZy0XgaV7815GBTfFwKUFwQ8 2P19vXpkWjDKnD4phu7QxbyPHYBMMMxUgr0KaYUSzuFbgHl7JGvtqFntcgvuOOyCxRU0YJWUW2U3 QmM7CrlpNieSEjjdvtVQfv5L3KZPs9aPCFWBhMl67Siz2jrj1AA0MK8AsoPY1V/En8+Th5LVUIky Y/flCDfhQq7LkFTfs2EkyB4Yn9+EqtVe6cC9Cad9XOVUk3EjzNslcC6z7obzdy5avw6gt7PDU8DO 6pv0QPBBaIbqTiqMz2atH95mOs/qjyBredqBzKErsuEyMID6w0XwRb0wFaqZMCc6y+8IRm5xrF7P rKw1I7kuq1BYrNcwn8u2GJ4GoFVn+VX8eSLa2errL+HPyCQLNCj5IHbXaWGv5XExNp56qjcgrdPl xE8M+/hbsBZS5ZnGkn3isa4CAHEM8gXcWU7u0m4Y1OD1txUv/GZUuhQj3ZV8qH7nXd6WBqNaB6rX zcXGd7aYPfLWzu5yLpzSJ8WH+Cg1+A7b7sDd0CEvDEZueeDW4fX5XexqpvZdr203LWF7JQ1AQx4N AM0BLvR+fDUWrbtyNfr3Sr84xUw1jGkPTfVV12PlOfTFI3i+ADdPZgM/TG/ivx9UPz1r8QQn6sH/ BI73RLjRyxt46c/CSz+1Mx0EwpeWF8XJNkQjiYW+hvCud3kPe9K357Adxk/F7LoJhrn+B5Dh6k9r B8tzQ1fLCMSYU1e7H5maEmGwqcFzt91GPWd/F7/3AgMP3AjyMHkRQFsztfd6bbdJCqMLawBa7WFg Ua4DiN6Kr19A66xS2D0HEKXv5ml9/dm7aZmvydeObyLFWDaK/UzU8CEkdZYBOUxz8d/7uPhrXAce 14fikIthwR5YjKQi164YIX8fvFbOQWXORQAq+gIenxA+gHoIkTGvA+jd9FFUKlvfOtnZh25h7U7g gnchsuth+NS+BiuSLNifKOcuHitno0YSOb19yHz04ejFEtUG3g5Uc6i8qHVQEfxnn0W0kSJ/Da5Z YjwJc1lU61ntvl7b/Sm37wA0AK1h/rEoPwaIIj5F/omWIMXAutchgq+G/+aZcNGhcYlhceQwCZrB iCRa1xnCySz1c7ahytjWYNb54FV+wn+uRv+HA5yrXT9rzZgNiOH+PyDSq3QDygVndzVBdFN/qFEj ZUDsITl2wgHgc10O+y2zqFaygBmcuftEliuQscKfsjp9C47ph31wHjDjvh1e2D98L2YVJTQsU0fL DLPuXszOt8VhniAW0x8ZuLwF8/kYirP5/UN98jFyDVyGgIXWJkYSvb29Jwoa2OXCbjvl8hqu+XRu H8kugjc/30qXxyF693NZi4vqCLD1j7o912trz1u4968BaC1PCIvyTYAodZWPofVUhzHrEhOLMDED K2tSP8pkDgRRivb5iBZah9/pAlVwRGqjL3HUzegXqFoPuY1viMHVH2F7t8D/L6K03CIrC2hF1kkh jDXvIT3bRd1a3yByF0Te+XCINyGU9L8osXx210A+t8DwcwHoj27uBzsNJoBeBg4Exu9N/qK+22vL 36EWcaMW/e2ic+eBQ74RDqFJSPfvjwlHwpZXtveQSwBoLZE2sK77WgbH+BXcaBhKirDSUAAtBOf5 ApKccJNUxCTJpc6PxJoSyD5Q/4y163qtf3hH7REagNbxaLEo3weIwhQvt6FdohCMQMkEymxBYmxx aPKQqn0iaFmeQ3uB/qYNWUkQPcnq3Z05cuVKGEFugUP/RInCNZA+z4F0Z8zQdA50o4ydbi066LII 08DZ4U5ld+mQ4DlGJSUmJ0re91uAwUObBsoy5rCkvo7379U9nbUntZ6keK014tr7xXwy0ushzOfP kCbORnqqoWBBJ8Dj17KyMF5tSBc2cEM6gPlnsbz6xPHQ0RQ6TUpdAH2sior6EeGZd68bLD1QfZVJ QmbvS5ZZe+kCjGdM/9lyVx7m8smsBY2by/Zar23/RMPnihqA1vMssChXAESvImagXYw2Fa1q2vqa wZPA+SHaO+ijwZxE6HCylg9/P3PkEkSdmCYgRvJEINc1YvEamVTinbzu4GKqGKZqvJM9MJRsgNjK UMbQ3JL1LcFNSP92yI3bpN4O6oL/bO0tiw7G4aW3C0GEMdpFSHSB8fiTU1S4/iXRSbPr67c9f8d8 /ozr/4w57Swe09vg7k8qPmSSu5DMmGqKcXEhm2K1gS5AYo8P8lNkBTjJO9I2qyxJDaWNZdGyrphp 6DBX4OZ3lEfJ31mamKILdyPmSjWhWTCPbu92eHz8AZFbjIxrNDVjvVKP8VFz1mujB3sUnKABaAMe IhOO4LA3AKSMGuqNdjfaWYFT+VuQs6TLCUX0r9F+wXnwxm8eIa8l9aUfQQz9VCyedJSpmFJcapLb swfDglyhstbXROUwWjD92WsQDe3Q972J9/HYhCox+HUObDl0cfsqwDVR1wocPeCJkG/3MJ8pdYc4 lcAZg0+Hzw3wfFm6me/K+qpxHFPzZqbpZ2NOD2QOWfYkEi6PlAh9Ql5ZpJy7dIw8lbFGzkTC5ZrE +Wehw3w3BwYezCXTCjYGQOmDugfXEBqrVMJizGk0WjBOgslovCiC50S0kcv9V+jBVzT97pRONHS9 Ui/AtTo8sHbjQvqGwrUypeXzOO//mnPd3+K5GoA24qnTeRmH0+GenFYQQFfi/8pvE0TjiQvHtbgR hWI9LMpZcIt6F/Jjl4OIrrl82Sh5YOAGZQSpzl3SIft/yCe5mcmM8cJ+Aa61oQBK8P0UPqgecqBM o+f2lYrP7UF94E4qyz7duZyeEuTy3wK3+efEffGrWV+tbz19QiOeUUMPBYc3Gy5j9+I+nsN9GXYi 5vyipaPlmp7blTifDPcmGs2KMAdLMYdLwXkiUxa618ncA4my/FBsjSU3ql8/D9b+13f2OFwEzuf7 DMesQWW40chlFxNwi9sGYP1IIkpnZy1vuXR/gfVKN6hfsWapRKfkFBre9h3+Hh0Yc/i4djT0IYbB cRqANu0hhLoOuhuq22zapQ6fhZjyH8E53SFu/UsSobMeQJaeG1cNkx/hnjMdRciSwZEaYaTY5zCr 7/LseGdUfXmdvK0cyfNkbBySmdRDnyKh7880eJDLdPtQIth7v+hMWxDLPwqAkwgu7CAMXCtQpPzb rAUZxUh/Xl+XYfl71srh/8F8Rotbd69EGWKc5UZ5PidNnoe6Io1pBAGYTMt3gKqKoJgN3/atEMfv RXq5j8YsqlMXSun80c39ZTkd45Vfp68Qus17s9YMz27rCcEapW66in4aoBpq4a+qlmrrAXbQ62kA 2rQHFwqgbeuHfdbnb8nHZ/K5/R2lkJMhQstH4HA+AkBaAJYE0DIYLYR+mYjAUTwHMvnmQ4S8By/9 x2MX1akL3QAn7qyNA5GonG5aONcjiwDC/8paPIpI3Lb5PJv2bBp1FjjRxzOHr94IrvoBsJwjlH+v zyA5ZZRuuffgbwYI+GsD+SDf6yiKf52fjPlMl4fS14OBPdK9i+D5COoaPb8FYj+z4VNP7PG+3h7g WceEtO3abdST6RgHawDaMZ5T5SjBSfggAP4vc8gS6FtN9yB0cgoSFlvoeO3wWOBJBLLx9VV+mU4A AkQzXaqYPPIdXJJoMHl00DphBqXqtB7GpmtREZK5KMXG8xGWadA9wQipDjZNjRpu1sqhn0PHvFxs 7rPh9XAN7rk75hWlRgPFLjyoWuATZEPSvYPvL4QP8PksLPjPnH6yoTRaMgdskMHRJUp36oWOlPP4 BFL6fbQrVSUGgJ6VuWUXicP0VKMGph0c9jOgAWjYP6KaBwhDw8+ZYxcukjLzDIiFF8EPsx84JFgq QHqdG2/yDnBN78EZ+2dxGx+G7815SMcuL8BZex1e8Nv75sjA6FKV5o1RMt9D5KfRyR+SCfAkBnt8 /5e1egT9V496YtQSbvLpzInZL0uJOxWbTgp0nn7zeIVxp+xelZ9VdLELrlDroMroL5GmET4k3P4a lnlWHWXSF7p4lUBnuh761FJ4KihtowJP9yYY327DNep3mzjqZ/roukENQDvw8wRnSIbzEza8+FHi 9EFxCXIa7XhZK+NH4bbzIAw+aXDQHolYUJkHsJwHN6QUm12JnyzBcRDGDoWaLINLcdUB48q+UgYR /KYIOl3WTmGmLLYQylD/hyvU5swhCy+WMt/98M+9ABsTKmpYZPFBeCwEw9IoGDOPJ8X2Mud8uILd mrVyzNLf1ET+Rm5WA9Cj5EHjxS/FrbAdQXDbWQvO6QIk5X0IYuh5KlM8HLjznWBYGdJIPR+NHEz6 7EKVd4/3H+IqfTRrT8tZhI+SafaD6JoJ68H9Xy5O2xzM183g/ocHUvn5Nx9/TfZsfL4H8HwN80+f YI2OwhmoDqD1Fx4/CiehCbcUdtE29d2D4pzSs6+GOxIS8fqugmFpHF52m1LaGaCqc/sKoN+biwxA r4r7op+z1ncst6T67r+lfw/ohV8Fd/+dOE3p2Jh6wltBx5kUl36rePW5HUxk73BruqWfaQP7q4KR 1QF0LFwb/Ho0jeqagfSOOD14ocmhfgTuCXrNOBR9ciNlnx3GElMZQGCrRJcczFo+Aa4tHdMtqT2e SYC7PBo4zHS8+yi2rFE9M4AM64epOoCiMrZGjZyBjlF3I+SmArrTbfiKTaPf7gywNHKQ/oz/sGnU iBkggDK+r3MjztEOrToD/pLEGmkz0PFmoOGxvR3v3tpixBUE0PvQHkdDGmyNGjkDyLIs7zTyHO1w bQbCZQaexUDoXoDysxo1cgYYxfWv/wcLBSJimc71aQAAAABJRU5ErkJggg== --_004_4A95BA014132FF49AE685FAB4B9F17F66B1C8D3Bsjceml521mbxchi_-- From nobody Mon Nov 19 12:17:46 2018 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 7966C129BBF for ; Mon, 19 Nov 2018 12:17:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VXH6q2dhWrZy for ; Mon, 19 Nov 2018 12:17:42 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 B60DA1292F1 for ; Mon, 19 Nov 2018 12:17:42 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id h3so8835741pfg.1 for ; Mon, 19 Nov 2018 12:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kLb0WH2AVFf4kgFliZdNcWciOzuxZ80vSnRKpXPzRgI=; b=Gb886JTblubI8xhl3jkxg6Fsm6RpKBJDF/+Pi6RsTpymi+9fh0+x47NAN/4olBbDQc MPl+jdclWiVyHUwQslk4rK+mCeZ04nfN75jEnRNJrC0MDCs+Ibpo7Dc6w0IoHqKwYcF5 YSFezjoBZ0LObOT0CHcc/fIP/HukkNCBZPi83+50Jowm2UTRDwV7/WOAz2/peDQlanWL acKZC9A/puv0LqyfyNtktbXKyiZhx0JZrQXY8OLo/KA2IrCON5tMjChcPH3ifYE5pfrz 1wBcYFGmCCsLwoJPzxcadRcIApJ2dtMT7DZXkfBs26GwXbV9ZOYqFtFqgnpYO0gJ97kZ sdFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kLb0WH2AVFf4kgFliZdNcWciOzuxZ80vSnRKpXPzRgI=; b=VFXwS8HvbI6MoMfPIMc6tZoTl0zx5UbnPCEvOwdaBG4vA7+Q/gY+QNKqki1eYY33jH T2rfKESZtxtASle6vR+wDOjFe2QrtKjwwlE8pfhvvuFzNuHTBkm3BZ3dUfGiPY3rB705 b5WdI6tH11yaG+PEpBr4dNVZdwxPp4RlSbPCI2nuGljtakLosd0ACnA8R8GlJAVswKcN Syq8WMkPHSF1JoEDsqP+6iXg+FEuShPy0IAQalU+9o2DYa+hTEBjsxR/nMbiGVqDEduh hTP0Xy8GjdO22lE1AF5z9AmhD5BLXm6eNi2x2crLP7NTZYIR0J4Re1w5F3I7bn+QqKor 6BRw== X-Gm-Message-State: AGRZ1gL62+O9lhAPitD+U+GrzRve6YP07Ks2qz7Ig1Koy6w5nJDzvG4d aridaS1RC4wPdZiXgK8znpU= X-Google-Smtp-Source: AJdET5fiXc3HAnLxRGqAmAbVcWwmqAv23liSZlqyovD1Gu9fHK54IfBXX8Mx3NrWytyqb2HdTk7vjg== X-Received: by 2002:a62:e201:: with SMTP id a1mr11711207pfi.75.1542658662028; Mon, 19 Nov 2018 12:17:42 -0800 (PST) Received: from ?IPv6:2601:1c0:cb00:da11:c1aa:1c99:72de:336c? ([2601:1c0:cb00:da11:c1aa:1c99:72de:336c]) by smtp.gmail.com with ESMTPSA id e23sm53212574pfh.68.2018.11.19.12.17.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:17:41 -0800 (PST) From: joel jaeggli Message-Id: <06E267FB-9751-44FF-887D-E0A304A58C85@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D27A097B-02A9-4962-AE35-200873A60B05" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Mon, 19 Nov 2018 12:17:40 -0800 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> Cc: IPsecME WG To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] Can one IPsec SA be established via two internet ports on one device? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:17:44 -0000 --Apple-Mail=_D27A097B-02A9-4962-AE35-200873A60B05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 19, 2018, at 11:19, Linda Dunbar > wrote: >=20 > IPsec experts,=20 > =20 > In the following diagram, CPE1 has two internet ports, A1 by one = service provider, A2 by another service provider. > CPE2 also have two ports facing two different internet service = providers > =20 > Question: can I establish ONE IPsec SA between CPE1 & CPE2? (i.e. = between 10.1.1.1 & 10.1.2.1)? > But the actual packets sent out from A1 port has to use A1 as = Source-Address, and using B1 or other public address as Destination = address. If in your example the source and destination IPs are sourced loopbacks = that are part of a prefix exported to the the isp(s) in each site then = you could in fact have one association=E2=80=A6 If the CPEs are using a provider assigned ip for tunnel termination = you=E2=80=99re going to need 4. We do the former all the time with sites multi-homed via bgp. > =20 > Or is it necessary to have one IPsec SA between A1<->B1, one IPsec SA = between A1<->B2, one IPsec SA between A2<->B1, and one IPsec SA between = A2<->B2? > =20 > =20 > > =20 > Thanks, Linda Dunbar > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_D27A097B-02A9-4962-AE35-200873A60B05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Nov 19, 2018, at 11:19, Linda Dunbar <linda.dunbar@huawei.com> wrote:

IPsec = experts, 
 
In the = following diagram, CPE1 has two internet ports, A1 by one service = provider, A2 by another service provider.
CPE2 also have two ports facing two = different internet service providers
 
Question: can I establish ONE IPsec SA = between CPE1 & CPE2? (i.e. between 10.1.1.1 & 10.1.2.1)?
But the = actual packets sent out from A1 port has to use A1 as Source-Address, = and using B1 or other public address as Destination = address.


If = in your example the source and destination IPs are sourced loopbacks = that are part of a prefix exported to  the the isp(s) in each site = then you could in fact have one association=E2=80=A6

If the CPEs are using a = provider assigned ip for tunnel termination  you=E2=80=99re going = to need 4.

We do the former = all the time with sites multi-homed via bgp.

 
Or is it = necessary to have one IPsec SA between A1<->B1, one IPsec SA = between A1<->B2, one IPsec SA between A2<->B1, and one IPsec = SA between A2<->B2?
          &nb= sp;            = ;            &= nbsp;       
 
<image001.png>
 
Thanks, Linda Dunbar
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_D27A097B-02A9-4962-AE35-200873A60B05-- From nobody Mon Nov 19 12:39:08 2018 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 564BD128D0C; Mon, 19 Nov 2018 12:39:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154265994634.16507.11786093943228748567.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 12:39:06 -0800 Archived-At: Subject: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:39:06 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5: "Enterprise Certificate Agency" --> I would have expected this to say Enterprise Certificate Authority. "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." Under what exceptional circumstances would it make sense to whitelist a TLD? Is this like if I run Example Corp and I own .example? From nobody Mon Nov 19 12:40:37 2018 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 73F46130E34; Mon, 19 Nov 2018 12:40:30 -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, 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=cooperw.in header.b=WWStcfLN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rC+RXcdg 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 X4H2JKCf87NC; Mon, 19 Nov 2018 12:40:26 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E10E130E65; Mon, 19 Nov 2018 12:40:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 950F8CD9; Mon, 19 Nov 2018 15:40:25 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 19 Nov 2018 15:40:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=bhgzd7XqXe5Z9Ph996jQnyH jYKdUr5IRc9U9cvgY7BA=; b=WWStcfLNVle1k4mPdHf2NxJa6SfvN4FwK+LV8QC sezv0heNM+/9/Gn2OrHfrbAegioIQ/alW3X7MWvN25hP8GqVQGF+ItBptzfbFNDE IrX47qT+S1Ed4J7pIlrNHYnrKe80LNXMrzPiKDjbgz9vl8fcYC2nOSx1Bl/efH8d xPSm8I/BcgrkCJQV2EcBsIVmqYhp5Wg30XpajNKshfy3mkERMM+BPVvTJuVTUZq/ 7130HkVa5KIBfQfdglFd0GPIQXa6Uzh13Z01zCs4hD3vTfjXGjH5MgonmCecHlvg toswlx6gETrQvAPlM472swQZJwHEj0Wwk8+y6ugr1xuTJuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bhgzd7 XqXe5Z9Ph996jQnyHjYKdUr5IRc9U9cvgY7BA=; b=rC+RXcdgntrPArmkTw640H 5OAWMuIsTDQm2R479BOrKIgCdiSCnekol2yDrgYm0axemKkKC1GdhQnzzNlkwyAw KBS54HsQ7HvluFUTa6UcnW4BbGjx38Nx2CkDXLh9OaU4K12XussVWR+Ix9NTn4/p +qd1otPI7y7ok0JI9ShNHYuQkJFJ0ZVjEn15PiwFHqTxkxuuhdaKroc/9+KgbaFO TtHI8UApnv2WX5augQ6sduewNYtkGFjQ0hucNDepT9YXI/7A/DoldeALcfI8GZYx yleJGZA5i7kINVgdsGMEvRxNLz8vagMsknhB/mwRjeBSG1oKbnD89w5PSzYwtd8Q == X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id B1BCCE4307; Mon, 19 Nov 2018 15:40:23 -0500 (EST) From: Alissa Cooper Message-Id: <8F85E7FC-DEEA-404E-A0B2-A376ADEECD32@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_857818F6-0CA2-4007-8E62-820B13DA5DAF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 19 Nov 2018 15:40:21 -0500 In-Reply-To: Cc: "ipsec@ietf.org" , "gen-art@ietf.org" , "draft-ietf-ipsecme-split-dns.all@ietf.org" To: Tommy Pauly , Christer Holmberg References: <153448715569.12184.4843735916628840351@ietfa.amsl.com> <220503CD-69AA-4015-A954-DF48D071D522@apple.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:40:36 -0000 --Apple-Mail=_857818F6-0CA2-4007-8E62-820B13DA5DAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Christer, thank you for your review. Tommy, thank you for addressing = Christer=E2=80=99s comments. I entered a No Objection ballot. Alissa > On Oct 22, 2018, at 4:26 PM, Tommy Pauly wrote: >=20 > Hi Christer, >=20 > Thanks again for the review. I've addressed all three comments below = in an update to the draft: >=20 > https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13 = > = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-split-dns-13.txt = >=20 > Thanks, > Tommy=20 >=20 >> On Aug 19, 2018, at 1:39 PM, Christer Holmberg = > = wrote: >>=20 >> Hi Tommy, >>=20 >> Please see inline. >>=20 >>=20 >> Minor issues: >>=20 >> Q1: >>=20 >>>> Section 3.1 contains some SHOULD-do statements, e.g.,: >>>>=20 >>>> "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and >>>> INTERNAL_IP6_DNS attributes in the CFG_REQUEST" >>>>=20 >>>> "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN = attributes >>>> in the CFG_REQUEST." >>>>=20 >>>> Is there a reason for not using MUST instead of SHOULD? >>>=20 >>> In general, the CFG_REQUEST attributes are a bit loose=E2=80=94they're= hints more than requirements. >>>=20 >>> =46rom section 3.15.1 of RFC7296: >>>=20 >>> The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to = request >>> information from its peer. If an attribute in the CFG_REQUEST >>> Configuration payload is not zero-length, it is taken as a = suggestion >>> for that attribute. The CFG_REPLY Configuration payload MAY return >>> that value, or a new one. It MAY also add new attributes and not >>> include some requested ones. Unrecognized or unsupported = attributes >>> MUST be ignored in both requests and responses. >>>=20 >>> So, the CFG_REPLY MUST have a DNS server to go along with the DNS = domain, but I left the SHOULD in spirit=20 >>> of the fact that the CFG_REQUEST is more of a suggestion. >>>=20 >>> That being said, if others in the WG would like to see this be a = MUST, I'm fine with that as well. I don't think we=20 >>> should have the responder error out if it doesn't see both, however. >>=20 >> Well, if it is only a suggestion, then I guess my question is why use = something as strong as SHOULD :) SHOULD basically means = MUST-unless-you-have-a-good-reason to. >>=20 >> In general, is providing suggestions a SHOULD, or is it only for the = attributes above? >>=20 >> Anyway, if you want to have a SHOULD (or even a MUST) I won't object. = But, when I see a SHOULD, I always ask about the background :) >>=20 >>=20 >> Q2: >>=20 >>>> Section 3.2 says: >>>>=20 >>>> "the initiator SHOULD behave as if Split DNS configurations are not = supported >>>> by the server." >>>>=20 >>>> Again, is there a reason for not using MUST? >>>=20 >>> This one could be a MUST. The one exception I could see is if the = initiator was statically configured with some split DNS domains to use = as split domains >>> In case the responder didn't provide any in the CFG_REPLY, it should = still use those and not send all DNS queries inside the tunnel. I = wouldn't want this >>> MUST to disable the static configuration workarounds that = implementations have done prior to allowing split DNS to be negotiated. >>=20 >> Could you say: >>=20 >> "the initiator MUST behave as if a Split DNS configurations are not = supported, unless " >>=20 >>=20 >>=20 >> Nits/editorial comments: >>=20 >> Q3: >>=20 >>>> Is there a need for the "Background" section? Since the text is = related to what >>>> is described in the "Introduction", could the the text be moved = there? >>>=20 >>> The main new points that the Background section adds on top of the = Introduction are: >>> - The prior art for split DNS in IKEv1 >>> - The fact that this is currently mainly seen in enterprise VPN = deployments >>>=20 >>> These points could indeed be moved to the introduction. I had felt = they fit better as "background" since they're=20 >>> not essential to the description of the protocol, but give context = that is relevant now (and may be less so in the future). >>=20 >> The first sections of both the Introduction and the Background = sections talk about split DNS: >>=20 >> "Split DNS is a common configuration for secure tunnels, such as >> Virtual Private Networks in which host machines private to an >> organization can only be resolved using internal DNS resolvers" >>=20 >> "Split DNS is a common configuration for enterprise VPN = deployments, >> in which one or more private DNS domains are only accessible and >> resolvable via an IPsec based VPN connection." >>=20 >> So, isn't Split DNS already covered by the Introduction? What extra = does the Background text bring? >>=20 >> The second paragraph of the Background could be placed at the end of = the Introduction, in my opinion. >>=20 >> Regards, >>=20 >> Christer >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_857818F6-0CA2-4007-8E62-820B13DA5DAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Christer, thank you for your review. Tommy, thank you for = addressing Christer=E2=80=99s comments. I entered a No Objection = ballot.

Alissa


On Oct = 22, 2018, at 4:26 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Christer,

Thanks again for the = review. I've addressed all three comments below in an update to the = draft:

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13=
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-split-= dns-13.txt

Thanks,
Tommy 

On Aug 19, 2018, at 1:39 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Tommy,

Please see inline.


Minor issues:

Q1:

Section 3.1 contains = some SHOULD-do statements, e.g.,:

"the = initiator SHOULD also include one or more INTERNAL_IP4_DNS and
INTERNAL_IP6_DNS attributes in the CFG_REQUEST"

"the initiator SHOULD also include one or more = INTERNAL_DNS_DOMAIN attributes
in the CFG_REQUEST."

Is there a reason for not using MUST instead = of SHOULD?

In general, the = CFG_REQUEST attributes are a bit loose=E2=80=94they're hints more than = requirements.

=46rom section 3.15.1 of = RFC7296:

 The CFG_REQUEST and = CFG_REPLY pair allows an IKE endpoint to request
 information from its peer.  If an attribute in the = CFG_REQUEST
 Configuration payload is not = zero-length, it is taken as a suggestion
 for that = attribute.  The CFG_REPLY Configuration payload MAY return
 that value, or a new one.  It MAY also add new = attributes and not
 include some requested ones. =  Unrecognized or unsupported attributes
 MUST be = ignored in both requests and responses.

So, = the CFG_REPLY MUST have a DNS server to go along with the DNS domain, = but I left the SHOULD in spirit 
of the fact = that the CFG_REQUEST is more of a suggestion.

That being said, if others in the WG would like to see this = be a MUST, I'm fine with that as well. I don't think we 
should have = the responder error out if it doesn't see both, however.

Well, if it is only a suggestion, then I guess my question is = why use something as strong as SHOULD :) SHOULD basically means = MUST-unless-you-have-a-good-reason to.

In general, is providing suggestions a SHOULD, or is it only = for the attributes above?

Anyway, if you want to have a SHOULD (or even a MUST) I won't = object. But, when I see a SHOULD, I always ask about the background = :)


Q2:

Section 3.2 says:

"the initiator SHOULD behave as if Split DNS = configurations are not supported
by the server."

Again, is there a reason for not using = MUST?

This one could be a = MUST. The one exception I could see is if the initiator was statically = configured with some split DNS domains to use as split domains
In case the responder didn't provide any in the CFG_REPLY, it = should still use those and not send all DNS queries inside the tunnel. I = wouldn't want this
MUST to disable the static = configuration workarounds that implementations have done prior to = allowing split DNS to be negotiated.

Could you say:

"the initiator MUST behave as if = a Split DNS configurations are not supported, unless <insert text = above the statically configuration case above>"



Nits/editorial = comments:

Q3:

Is there a need for the = "Background" section? Since the text is related to what
is = described in the "Introduction", could the the text be moved there?

The main new points that the = Background section adds on top of the Introduction are:
- = The prior art for split DNS in IKEv1
- The fact that this = is currently mainly seen in enterprise VPN deployments

These points could indeed be moved to the introduction. I had = felt they fit better as "background" since they're 
not = essential to the description of the protocol, but give context that is = relevant now (and may be less so in the future).

The first sections of both the Introduction and the = Background sections talk about split DNS:

  "Split DNS is a common configuration for secure = tunnels, such as
  Virtual Private Networks in which host machines = private to an
  organization can only be resolved using internal = DNS resolvers"

  "Split DNS is a common configuration for = enterprise VPN deployments,
  in which one or more private DNS domains are only = accessible and
  resolvable via an IPsec based VPN = connection."

So, isn't = Split DNS already covered by the Introduction? What extra does the = Background text bring?

The second paragraph of the Background could be placed at the = end of the Introduction, in my opinion.

Regards,

Christer

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

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_857818F6-0CA2-4007-8E62-820B13DA5DAF-- From nobody Mon Nov 19 13:16:10 2018 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 82222130DE8 for ; Mon, 19 Nov 2018 13:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9gdhDV4aE9SC for ; Mon, 19 Nov 2018 13:16:06 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BEFB4130DE5 for ; Mon, 19 Nov 2018 13:16:05 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 93A60578454F0 for ; Mon, 19 Nov 2018 21:15:58 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Nov 2018 21:16:00 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.160]) by SJCEML701-CHM.china.huawei.com ([169.254.3.19]) with mapi id 14.03.0415.000; Mon, 19 Nov 2018 13:15:57 -0800 From: Linda Dunbar To: joel jaeggli CC: IPsecME WG Thread-Topic: [IPsec] Can one IPsec SA be established via two internet ports on one device? Thread-Index: AQHUgETzN+OjIGezU0mzBNgbBZ2EfqVXmQvQ Date: Mon, 19 Nov 2018 21:15:57 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1CBE26@sjceml521-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> <06E267FB-9751-44FF-887D-E0A304A58C85@gmail.com> In-Reply-To: <06E267FB-9751-44FF-887D-E0A304A58C85@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.120.13] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1CBE26sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] Can one IPsec SA be established via two internet ports on one device? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 21:16:09 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B1CBE26sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KVGhhbmtzIGZvciB0aGUgaGVscC4NCg0KV2hlbiB5b3Ugc2FpZCDigJxJUHMgYXJl IHNvdXJjZWQgbG9vcGJhY2tzIHRoYXQgYXJlIHBhcnQgb2YgYSBwcmVmaXggZXhwb3J0ZWQgdG8g dGhlIHRoZSBpc3AocykgaW4gZWFjaCBzaXRl4oCdLCBkbyB5b3UgbWVhbiB0aGF0IHRoZSBwcml2 YXRlIExvb3BiYWNrIGFkZHJlc3NlcyBvZiBDUEUxICYgQ1BFMiBhcmUgcm91dGFibGUgaW4gYWxs IGZvdXIgIElTUHPigJkgdGhhdCBjb25uZWN0ZWQgdG8gQTEsIEEyLCBCMSwgQjI/DQoNCkxpbmRh DQoNCkZyb206IGpvZWwgamFlZ2dsaSBbbWFpbHRvOmpvZWxqYUBnbWFpbC5jb21dDQpTZW50OiBN b25kYXksIE5vdmVtYmVyIDE5LCAyMDE4IDI6MTggUE0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRh LmR1bmJhckBodWF3ZWkuY29tPg0KQ2M6IElQc2VjTUUgV0cgPGlwc2VjQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtJUHNlY10gQ2FuIG9uZSBJUHNlYyBTQSBiZSBlc3RhYmxpc2hlZCB2aWEgdHdv IGludGVybmV0IHBvcnRzIG9uIG9uZSBkZXZpY2U/DQoNCg0KDQoNCk9uIE5vdiAxOSwgMjAxOCwg YXQgMTE6MTksIExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb208bWFpbHRvOmxp bmRhLmR1bmJhckBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCklQc2VjIGV4cGVydHMsDQoNCkluIHRo ZSBmb2xsb3dpbmcgZGlhZ3JhbSwgQ1BFMSBoYXMgdHdvIGludGVybmV0IHBvcnRzLCBBMSBieSBv bmUgc2VydmljZSBwcm92aWRlciwgQTIgYnkgYW5vdGhlciBzZXJ2aWNlIHByb3ZpZGVyLg0KQ1BF MiBhbHNvIGhhdmUgdHdvIHBvcnRzIGZhY2luZyB0d28gZGlmZmVyZW50IGludGVybmV0IHNlcnZp Y2UgcHJvdmlkZXJzDQoNClF1ZXN0aW9uOiBjYW4gSSBlc3RhYmxpc2ggT05FIElQc2VjIFNBIGJl dHdlZW4gQ1BFMSAmIENQRTI/IChpLmUuIGJldHdlZW4gMTAuMS4xLjEgJiAxMC4xLjIuMSk/DQpC dXQgdGhlIGFjdHVhbCBwYWNrZXRzIHNlbnQgb3V0IGZyb20gQTEgcG9ydCBoYXMgdG8gdXNlIEEx IGFzIFNvdXJjZS1BZGRyZXNzLCBhbmQgdXNpbmcgQjEgb3Igb3RoZXIgcHVibGljIGFkZHJlc3Mg YXMgRGVzdGluYXRpb24gYWRkcmVzcy4NCg0KDQpJZiBpbiB5b3VyIGV4YW1wbGUgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gSVBzIGFyZSBzb3VyY2VkIGxvb3BiYWNrcyB0aGF0IGFyZSBwYXJ0 IG9mIGEgcHJlZml4IGV4cG9ydGVkIHRvICB0aGUgdGhlIGlzcChzKSBpbiBlYWNoIHNpdGUgdGhl biB5b3UgY291bGQgaW4gZmFjdCBoYXZlIG9uZSBhc3NvY2lhdGlvbuKApg0KDQpJZiB0aGUgQ1BF cyBhcmUgdXNpbmcgYSBwcm92aWRlciBhc3NpZ25lZCBpcCBmb3IgdHVubmVsIHRlcm1pbmF0aW9u ICB5b3XigJlyZSBnb2luZyB0byBuZWVkIDQuDQoNCldlIGRvIHRoZSBmb3JtZXIgYWxsIHRoZSB0 aW1lIHdpdGggc2l0ZXMgbXVsdGktaG9tZWQgdmlhIGJncC4NCg0KDQoNCk9yIGlzIGl0IG5lY2Vz c2FyeSB0byBoYXZlIG9uZSBJUHNlYyBTQSBiZXR3ZWVuIEExPC0+QjEsIG9uZSBJUHNlYyBTQSBi ZXR3ZWVuIEExPC0+QjIsIG9uZSBJUHNlYyBTQSBiZXR3ZWVuIEEyPC0+QjEsIGFuZCBvbmUgSVBz ZWMgU0EgYmV0d2VlbiBBMjwtPkIyPw0KDQoNCjxpbWFnZTAwMS5wbmc+DQoNClRoYW5rcywgTGlu ZGEgRHVuYmFyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F66B1CBE26sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Sm9lbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIGZvciB0aGUgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldoZW4geW91IHNhaWQg4oCcPC9zcGFuPklQcyBhcmUgc291cmNlZCBsb29w YmFja3MgdGhhdCBhcmUgcGFydCBvZiBhIHByZWZpeCBleHBvcnRlZCB0byB0aGUgdGhlIGlzcChz KSBpbiBlYWNoIHNpdGXigJ0sDQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZG8geW91 IG1lYW4gdGhhdCB0aGUgcHJpdmF0ZSBMb29wYmFjayBhZGRyZXNzZXMgb2YgQ1BFMSAmYW1wOyBD UEUyIGFyZSByb3V0YWJsZSBpbiBhbGwgZm91ciZuYnNwOyBJU1Bz4oCZIHRoYXQgY29ubmVjdGVk IHRvIEExLCBBMiwgQjEsIEIyPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5MaW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gam9lbCBqYWVnZ2xpIFttYWlsdG86am9lbGph QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDE4 IDI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IExpbmRhIER1bmJhciAmbHQ7bGluZGEuZHVuYmFyQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJUHNlY01FIFdHICZsdDtpcHNlY0BpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10gQ2FuIG9uZSBJUHNlYyBTQSBi ZSBlc3RhYmxpc2hlZCB2aWEgdHdvIGludGVybmV0IHBvcnRzIG9uIG9uZSBkZXZpY2U/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDE5LCAy MDE4LCBhdCAxMToxOSwgTGluZGEgRHVuYmFyICZsdDs8YSBocmVmPSJtYWlsdG86bGluZGEuZHVu YmFyQGh1YXdlaS5jb20iPmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPklQc2VjIGV4cGVydHMsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J biB0aGUgZm9sbG93aW5nIGRpYWdyYW0sIENQRTEgaGFzIHR3byBpbnRlcm5ldCBwb3J0cywgQTEg Ynkgb25lIHNlcnZpY2UgcHJvdmlkZXIsIEEyIGJ5IGFub3RoZXIgc2VydmljZSBwcm92aWRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkNQRTIgYWxzbyBoYXZlIHR3byBwb3J0cyBmYWNpbmcgdHdvIGRp ZmZlcmVudCBpbnRlcm5ldCBzZXJ2aWNlIHByb3ZpZGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5RdWVzdGlvbjogY2FuIEkgZXN0YWJsaXNoIE9ORSBJUHNl YyBTQSBiZXR3ZWVuIENQRTEgJmFtcDsgQ1BFMj8gKGkuZS4gYmV0d2VlbiAxMC4xLjEuMSAmYW1w OyAxMC4xLjIuMSk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CdXQgdGhlIGFjdHVhbCBwYWNrZXRzIHNl bnQgb3V0IGZyb20gQTEgcG9ydCBoYXMgdG8gdXNlIEExIGFzIFNvdXJjZS1BZGRyZXNzLCBhbmQg dXNpbmcgQjEgb3Igb3RoZXIgcHVibGljIGFkZHJlc3MgYXMgRGVzdGluYXRpb24gYWRkcmVzcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBpbiB5b3VyIGV4YW1wbGUgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gSVBzIGFyZSBzb3VyY2VkIGxvb3BiYWNrcyB0aGF0IGFyZSBwYXJ0 IG9mIGEgcHJlZml4IGV4cG9ydGVkIHRvICZuYnNwO3RoZSB0aGUgaXNwKHMpIGluIGVhY2ggc2l0 ZSB0aGVuIHlvdSBjb3VsZCBpbiBmYWN0IGhhdmUgb25lIGFzc29jaWF0aW9u4oCmPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBDUEVz IGFyZSB1c2luZyBhIHByb3ZpZGVyIGFzc2lnbmVkIGlwIGZvciB0dW5uZWwgdGVybWluYXRpb24g Jm5ic3A7eW914oCZcmUgZ29pbmcgdG8gbmVlZCA0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRvIHRoZSBmb3JtZXIgYWxsIHRoZSB0aW1lIHdpdGgg c2l0ZXMgbXVsdGktaG9tZWQgdmlhIGJncC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5PciBpcyBpdCBuZWNlc3NhcnkgdG8gaGF2ZSBvbmUgSVBzZWMgU0Eg YmV0d2VlbiBBMSZsdDstJmd0O0IxLCBvbmUgSVBzZWMgU0EgYmV0d2VlbiBBMSZsdDstJmd0O0Iy LCBvbmUgSVBzZWMgU0EgYmV0d2VlbiBBMiZsdDstJmd0O0IxLCBhbmQgb25lIElQc2VjIFNBIGJl dHdlZW4gQTImbHQ7LSZndDtCMj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O2ltYWdl MDAxLnBuZyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGFua3MsIExpbmRhIER1bmJhcjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KSVBzZWMgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJUHNl Y0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5JUHNlY0BpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl Yzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F66B1CBE26sjceml521mbxchi_-- From nobody Mon Nov 19 14:24:31 2018 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 746DD1252B7 for ; Mon, 19 Nov 2018 14:24:30 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, 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 TpYf0gxjg72P for ; Mon, 19 Nov 2018 14:24:28 -0800 (PST) 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 9DAA212D4E7 for ; Mon, 19 Nov 2018 14:24:28 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7BCE320089; Mon, 19 Nov 2018 17:24:21 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C736ED8B; Mon, 19 Nov 2018 17:24:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C456FD85; Mon, 19 Nov 2018 17:24:25 -0500 (EST) From: Michael Richardson To: Linda Dunbar cc: joel jaeggli , IPsecME WG In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B1CBE26@sjceml521-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> <06E267FB-9751-44FF-887D-E0A304A58C85@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B1CBE26@sjceml521-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Can one IPsec SA be established via two internet ports on one device? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 22:24:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Linda Dunbar wrote: > When you said =E2=80=9CIPs are sourced loopbacks that are part of a p= refix > exported to the the isp(s) in each site=E2=80=9D, do you mean that th= e private > Loopback addresses of CPE1 & CPE2 are routable in all four ISPs=E2=80= =99 that > connected to A1, A2, B1, B2? No, he is saying that the CPE1 and CPE2 are each using provider independent address space and are multihomed to ISP1/ISP2 and ISP3/ISP4 respectively. If the *private* addresss space of CPE1/CPE2 were visible to the ISPs, then it wouldn't really be a V*Private*N. Such things are common in MPLS, ATM, FrameRelay, and the newer L3VPN technologies that are sold as managed solutions. You need four IPsec SAs. They could be transport+GRE/IPIP tunnels rather than IPsec Tunnel model SAs with a routing protocol on-top though. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvzOBkACgkQgItw+93Q 3WXvOwf+O6bv0uXmxoHy4HLHp0W9RiRSpEX9imAy4170gxA9NYTwZkD53fq9wpRf XqNKM3rvGaFLVnWzHLf68RoUkzgkRGF5F2rj3Y4P2Ni6OLFw9MGK193WUq/NGi3g Zp18YVpviTjW5WFzRe6RDkJG9K74FuvwjSU1GiQfBy8+7Z852O1yi0nss/C9ty3n meuWVDufL63l/OKNlu2yqIcbyJXd6C1KH8C4LyG69wkD/rFsuI+O+aLEZVi+VvDh 7uhtyM4ajWb7RC9SqLB75/pWSIenI/w9w06/x6juuxOH0OknwidtWG7idWwOjlCn 16zK7NYZEg69SUDav+9ezDilqplJsw== =GWRq -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 19 19:23:52 2018 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 806291276D0 for ; Mon, 19 Nov 2018 19:23:50 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 AolUpCc88jsB for ; Mon, 19 Nov 2018 19:23:48 -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 7A675124BAA for ; Mon, 19 Nov 2018 19:23:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42zWJK152Rz3H3; Tue, 20 Nov 2018 04:23:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542684225; bh=hhtp7QGuOMwUuSHb9Y61gr4LGf1/+4CfkODv/oFmqbo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qNnzfXT4SiDOu3tZ+gzUgdOrQWcoHUCJCZ0aIjqbZj9/3BLwCBO+3xUAYOZCPDijg ADeyxDxyCMfu0h7hgN+XgHuFip1ZckLb88caz3R5blZHNGOs7ebJAK694wAOOZdIX1 rLHHpfSn2l+ijqHZLHF31lDL4DEXUSk/enleg35w= 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 K9cd-fnUJWZz; Tue, 20 Nov 2018 04:23:43 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Nov 2018 04:23:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AF95F4AA4D9; Mon, 19 Nov 2018 22:23:42 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AF95F4AA4D9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A5D5541C3B27; Mon, 19 Nov 2018 22:23:42 -0500 (EST) Date: Mon, 19 Nov 2018 22:23:42 -0500 (EST) From: Paul Wouters To: Linda Dunbar cc: IPsecME WG In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B1CBE26@sjceml521-mbx.china.huawei.com> Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B1C8D3B@sjceml521-mbx.china.huawei.com> <06E267FB-9751-44FF-887D-E0A304A58C85@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B1CBE26@sjceml521-mbx.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Can one IPsec SA be established via two internet ports on one device? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 03:23:50 -0000 On Mon, 19 Nov 2018, Linda Dunbar wrote: > When you said “IPs are sourced loopbacks that are part of a prefix exported to the the isp(s) in each site”, > do you mean that the private Loopback addresses of CPE1 & CPE2 are routable in all four  ISPs’ that > connected to A1, A2, B1, B2? And to clarify, assuming your IPsec connection does not cover the IPs used on both endpoints, but instead is some kind of subnet behind your servers, then you can one IPsec SA. It does require some tricks if you really want to limit it to one IPsec SA. Remember that while you can choose which outgoing interface to use, you cannot choose the incoming device, so it would be a poor load balance. It is far easier to use two IPsec SA's that cover the same site-to-site range. On Linux, the easiest would be to setup two identical subnet-to-subnet IPsec SA with a different XFRM mark. Then create a VTI device for each of these. Then you can use routing and traffic shaping/control to send packets to one or the other VTI interface for load balancing. If one of the links goes down, the interface goes down and it all goes over the remaining interace. Libreswan and strongswan support this. For libreswan, use: conn one [basic config] mark=8/0xffffffff vti-interface=ispA vti-routing=no vti-shared=no conn two [basic config] mark=7/0xffffffff vti-interface=ispB vti-routing=no vti-shared=no Then handle the routing/traffic control yourself. Another solution for this is using MOBIKE, but then you are only using one of the two in a failover type of scenario, and it is not doing any kind of load balancing. Again libreswan and strongswan support this. Paul From nobody Mon Nov 19 22:27:43 2018 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 2BCAB1277D2; Mon, 19 Nov 2018 22:27:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154269526117.26570.16079585187213164139.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 22:27:41 -0800 Archived-At: Subject: [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 06:27:41 -0000 Adam Roach has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. It seems a very useful extension to IKEv2. I have a handful of minor and editorial comments that you may want to consider addressing. --------------------------------------------------------------------------- Please expand "IKEv2" in the title and abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for details. --------------------------------------------------------------------------- §2.1: > To indicate support for Split DNS, an initiator includes one more > INTERNAL_DNS_DOMAIN attributes as defined in Section 3 as part of the > CFG_REQUEST payload. I can't parse this. Is it mean to say "...one or more..."? Or is "attributes" supposed to be "attribute"? --------------------------------------------------------------------------- §2.1: > includes an INTERNAL_DNSSEC_TA attribute, but does not inclue an Nit: "include" --------------------------------------------------------------------------- §2.1: > An initiator MAY convey its current DNSSEC trust anchors for the > domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does > not wish to convey this information, it MUST use a length of 0. As an implementor, I would have no idea whether this was something I wanted to include. If it is configurable, then I would have no idea as an operator whether how to set such configuration. Could we add some guidance here about when implementations and/or operators might want to send this, and when they might not? --------------------------------------------------------------------------- §2.4.1: > The responder replies with two DNS server addresses, and two internal > domains, "example.com" and "city.other.com". The domain "other.com" appears to be in active use by an organization known as "Other Entertainment." Please consider using an example domain as described in RFC 2606 section 2 or 3. --------------------------------------------------------------------------- §2.4.2: > In this example, the initiator has no existing DNSSEC trust anchors > would the requested domain. the "example.com" dommain has DNSSEC Nit: "...domain. The..." --------------------------------------------------------------------------- §4: > For example, if the INTERNAL_DNS_DOMAIN attribute > specifies "example.com", then "example.com", "www.example.com" and > "mail.eng.example.com" MUST be resolved using the internal DNS > resolver(s), but "anotherexample.com" and "ample.com" SHOULD NOT be > resolved using the internal resolver and SHOULD use the system's > external DNS resolver(s). The domain "anotherexample.com" is in use by a personal web site. The domain "ample.com" is registered anonymously through Amazon.com. For this example that needs to show a domain whose name is a subset of the indicated domain, please consider using an example domain as described in RFC 2602 section 2. --------------------------------------------------------------------------- §5: > DNS records can be used to publish specific records containing trust > anchors for applications. The most common record type is the TLSA > record specified in [RFC6698]. This DNS record type publishes which > CA certificate or EE certificate to expect for a certain host name. Please expand "CA" and "EE". --------------------------------------------------------------------------- §5: > In most deployment scenario's, the IKE client has an expectation that Nit: "scenarios" From nobody Tue Nov 20 02:46:51 2018 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 6B45A12F18C; Tue, 20 Nov 2018 02:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_XPILL=2.799, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 GngqzQ0mh40q; Tue, 20 Nov 2018 02:46:40 -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 5BEEC128CF2; Tue, 20 Nov 2018 02:46:39 -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 wAKAkQjE006565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Nov 2018 12:46:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAKAkQgx028294; Tue, 20 Nov 2018 12:46:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23539.58882.139191.731005@fireball.acr.fi> Date: Tue, 20 Nov 2018 12:46:26 +0200 From: Tero Kivinen To: Paul Wouters Cc: Paul Wouters , "ipsecme-chairs\@ietf.org" , "Waltermire\, David A. \(Fed\)" , "ipsec\@ietf.org" , The IESG , "draft-ietf-ipsecme-split-dns\@ietf.org" , Benjamin Kaduk In-Reply-To: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 23 min X-Total-Time: 34 min Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 10:46:43 -0000 Paul Wouters writes: > The authors would have been happy with full presentation format for > both :) > > You were the one that raised an issue that strings would be passed > carelessly and could be abused by peer's to try and get a shell :P Yes, as I have seen so many times that people pass strings for configuration directly from the remote end to the configuration file, either because of it is easy, or by accident (shellshock, all kind of CGI issues etc). Using wireformat and forcing IKE library to do one line of code to convert wireformat to restricted presentation format removes that kind of issues: printf("DS %d %d %d %s\n", unpack("nCCH*", $cfg_payload)); On the other hand generating the wire format from the values coming from configuration is similarly very easy (provided it comes from normal config file not from dns configuration file): $cfg_payload = pack("nCCH*", $dnskey_key_tag, $dnskey_alg, $digest_type, $digest_data_in_hex); On the other hand parsing presentation format is much harder issue... > > > > INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656 ; comments > > D14D9246558 ; in file > > 77628FFD6A98D7A847E ) ; more") > > I don't remember that I wanted to have comments. If I did, I certainly > don't care now and I would be happy to move everything back to DNS > presentation format. Presentation format includes things like comments, newlines, whitespace etc. That is the reason I do not like to have presentation format inside the binary wire formats like IKE. We do not need to do string parsing, or regex processing in IKE library, but to properly parse presentation format you need to do that. > I would not want to use wireformat anywhere, because as I argued in the > past, the IKE daemon is just passing on this information and for it to > need to convert its DNS configuration, which is guaranteed to be in DNS > presentation format, it would need to copy some DNS conversion code or > link against some DNS library to convert it to wire format. I do not see any reason why the incoming configuration from IKE is going to be in the presentation format. I think most people do use configuration formats like: modecfgdns1=1.2.3.4 modecfgdns2=8.8.8.8 modecfgdomain1=example.com modecfgtadnsseckeytag1=1270 modecfgtadnssecalg1=8 modecfgtadigesttype1=1 modecfgtadigestdata1=506AD3A656... or pseudo presentation format (which really isn't presentation format as it does not allow comments or newlines inside () etc). modecfgta1=1270 8 1 506AD3A656... > And a security check could simply reject all characters outside > [A-Za-z0-9\-_\.]* For presentation format that is not enough (for example it does not git rid of comments or newlines and paranthesis), and even then it is wrong is it does not allow any whitespace. For pseudo simplified presentation format it is too much, as it allows dash, underline, and period which are not needed... > On the other end, passing the DNS information from IKE daemon to the > system is most likely happening over a DNS presentation API as well, as > all API's supporting commandline configurations cannot take DNS wire > format but take DNS presentation format. As I said converting wire format to simplified presentation format (which is still valid presentation format) is trivial. > So I think we have two options: > > 1) Clarify the text that the DS RRtype data is not in either wire or > presentation format. Yes. This is needed. I would actually also would like to have text explaining can you have comments whitespace, newlines etc inside the Digest Data or not too, while we are at it. I would expect that most of the implementations would not necessarely like those and sending those over the wire is just wasting bytes. > 2) Change the DS RRtype data to also be fully DNS presentation format. > > > I have a preference for 2) but I guess the working group in the past > reached consensus on 1) > > > Which is then encoded as: > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-----------------------------+-------------------------------+ > > |R| Attribute Type 0x19 | Length 0x48 | > > +-+-----------------------------+---------------+---------------+ > > | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| > > +-------------------------------+---------------+---------------+ > > | 0x28 "(" 0x20 " " 0x35 "5" 0x30 "0" | > > | 0x36 "6" 0x41 "A" 0x44 "D" 0x33 "3" | > > | 0x41 "A" 0x36 "6" 0x35 "5" 0x36 "6" | > > | 0x20 " " 0x20 " " 0x2B ";" 0x20 " " | > > | 0x63 "c" 0x6f "o" 0x6d "m" 0x6d "m" | > > | 0x65 "e" 0x6e "n" 0x74 "t" 0x73 "s" | > > | 0x0a "\n" 0x09 "\t" 0x09 "\t" 0x44 "D" | > > | 0x31 "1" 0x34 "4" 0x44 "D" 0x39 "9" | > > | ... | > > +---------------------------------------------------------------+ > > > > and so on, instead of: > > > > INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E) > > > > with DS wire format encoding for Digest Data would result following > > attribute: > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-----------------------------+-------------------------------+ > > |R| Attribute Type 0x19 | Length 0x1c | > > +-+-----------------------------+---------------+---------------+ > > | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1| > > +-------------------------------+---------------+---------------+ > > | 0x50 0x6a 0xd3 0xa6 | > > | 0x56 0xd1 0x4d 0x92 | > > | 0x46 0x55 0x87 0x76 | > > | 0x28 0xff 0xd6 0xa9 | > > | 0x8d 0x7a 0x84 0x7e | > > +---------------------------------------------------------------+ -- kivinen@iki.fi From nobody Tue Nov 20 06:33:34 2018 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 7C94612D4F2 for ; Tue, 20 Nov 2018 06:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 W6JpXGtpki-C for ; Tue, 20 Nov 2018 06:33:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949F31286E3 for ; Tue, 20 Nov 2018 06:33:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F266920089 for ; Tue, 20 Nov 2018 09:33:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 572B6B56; Tue, 20 Nov 2018 09:33:27 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 544229DB for ; Tue, 20 Nov 2018 09:33:27 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org" In-Reply-To: <23539.58882.139191.731005@fireball.acr.fi> References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> <23539.58882.139191.731005@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:33:32 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Presentation format includes things like comments, newlines, > whitespace etc. > That is the reason I do not like to have presentation format inside > the binary wire formats like IKE. We do not need to do string parsing, > or regex processing in IKE library, but to properly parse presentation > format you need to do that. +1 For all the reasons you cited. (Mind, I think split-horizon dns is perpetuation of a bad idea from 1989. Unrouted IPv6 for internal use has no split-dns needs, so I don't really care if gateway's will find a way to attack client systems.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv0GzYACgkQgItw+93Q 3WVcCQf9Gy8mBpKxr9EQQdA2HFzmRjETXpvODMA4p/aGeFNVXrLpCuJYN5q/9RXD TZpGuhdfFRLDJmikHL4oD1PYpJna46pATXpb6h82HpusbYFCDBtL6qhxkVZSQr8e dcHWVHt1cqezrRcPzy+mS84JvxpJL1ohLrSCaX3lFOUvBU2mDdcZMT/ZmSiKAXfU 9Tr6DOAq0ugA4Jb8eOL6muRFZYiS5WRvj2jXlXxVHo4KiEijm9s+tEITXmr9RCF5 qFGX6CJ7DYkhH5IuNJl0NU7RbisKPuiYhM4k4P54peKp59VlHywy8JHwEErAoaSG oWDDRhToMCUZWzfjrGLr1bNLJML6Uw== =glwH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 20 06:46:16 2018 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 10EBD1274D0 for ; Tue, 20 Nov 2018 06:46:15 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 olzQ9GbpKnDo for ; Tue, 20 Nov 2018 06:46:12 -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 B2DE4126BED for ; Tue, 20 Nov 2018 06:46:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42zpRk4q42zL8g for ; Tue, 20 Nov 2018 15:46:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542725170; bh=SDhghvK7nLVqB0RQPAZVnJze4qtciaL+UlrO5NQ79jM=; h=Date:From:To:Subject:In-Reply-To:References; b=T5RmU/ahm9tXTl7k4ggejRCU9F9vcNUVeuSMqPPtLroCbcXjuZRVLbVwa+Sphg4th gZHplYNcmqt6w4zS0z3h4x+W+acVR7E/F44FdpS0QRRVMDmmW84wv7oUYMah7DSqMS DChuGWeRAljN2/qWeuaOr00okqMRCSXeqtxWzFwk= 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 2cCd7zabe_9X for ; Tue, 20 Nov 2018 15:46:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 20 Nov 2018 15:46:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 874784AA4C6; Tue, 20 Nov 2018 09:46:08 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 874784AA4C6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7B7E641C3B2D for ; Tue, 20 Nov 2018 09:46:08 -0500 (EST) Date: Tue, 20 Nov 2018 09:46:08 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <4812.1542724407@localhost> Message-ID: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> <23539.58882.139191.731005@fireball.acr.fi> <4812.1542724407@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:46:15 -0000 On Tue, 20 Nov 2018, Michael Richardson wrote: > Tero Kivinen wrote: > > Presentation format includes things like comments, newlines, > > whitespace etc. > > > That is the reason I do not like to have presentation format inside > > the binary wire formats like IKE. We do not need to do string parsing, > > or regex processing in IKE library, but to properly parse presentation > > format you need to do that. > > +1 > For all the reasons you cited. Parsing wouldn't happen the way Tero envisions this. IKE software like have something like an option that reads RRTYPEs, so that a DNS/VPN administrator can do: dig ds internal.example.com > /etc/ipsec.d/internal.example.com.ds dig ns internal.example.com > /etc/ipsec.d/internal.example.com.ns And put that in a cron job in case they do internal DNSSEC with key rollovers. with a config line in the IKE config that loads these entries. conn example.com modecfgdns=example.com modecfgdns-ns=/etc/ipsec.d/internal.example.com.ns modecfgdns-ds=/etc/ipsec.d/internal.example.com.ds [...] Paul From nobody Tue Nov 20 07:06:25 2018 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 4268C130DCB; Tue, 20 Nov 2018 07:06:13 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 yAy6WSvQmIi5; Tue, 20 Nov 2018 07:06:12 -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 F0F1212D4F2; Tue, 20 Nov 2018 07:06:11 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42zptk4zRvzL8f; Tue, 20 Nov 2018 16:06:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542726366; bh=yqXBzgqG6jBwJxETVXZG4IRUnm48Y/ucOwMetk7tRvo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JdVeFiwpP48zHNj3Gzj8Ns90pzhrvqbqrz3sVYIX6XmS133r+G2x8Rwqrm6TRgpv+ 5gCLi1r5mqYWAfEJHW3K/Se5qBR6DQagtQL8pT8/gD7IZV7LkIpCCH3pmoDRkPpS6d iXLLMmL/Wde5mwWChw5KDyE+xTB4BHIJ4314o7Qs= 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 6XVFXg7350hY; Tue, 20 Nov 2018 16:06:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Nov 2018 16:06:01 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 780374AA4C6; Tue, 20 Nov 2018 10:06:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 780374AA4C6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6D2A241C3B2D; Tue, 20 Nov 2018 10:06:00 -0500 (EST) Date: Tue, 20 Nov 2018 10:06:00 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: Paul Wouters , "ipsecme-chairs@ietf.org" , "Waltermire, David A. (Fed)" , "ipsec@ietf.org" , The IESG , "draft-ietf-ipsecme-split-dns@ietf.org" , Benjamin Kaduk In-Reply-To: <23539.58882.139191.731005@fireball.acr.fi> Message-ID: References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> <23539.58882.139191.731005@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 15:06:13 -0000 On Tue, 20 Nov 2018, Tero Kivinen wrote: > Yes, as I have seen so many times that people pass strings for > configuration directly from the remote end to the configuration file, > either because of it is easy, or by accident (shellshock, all kind of > CGI issues etc). That's why we have the Security Considerations: The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly. > Using wireformat and forcing IKE library to do one line of code to > convert wireformat to restricted presentation format removes that kind > of issues: Sure, but it would add two conversions that shouldn't be needed at all. > On the other hand generating the wire format from the values coming > from configuration is similarly very easy (provided it comes from > normal config file not from dns configuration file): Most likely, when automating this, it would be coming from live DNS output, eg the dig command. And not some new config file syntax for this. If I wouldnt use files as in my previous email's example, I would still want to be able to configure it like: modecfgdns-ds="example.com. IN DS 12345 8 1 BLOB" But pointing to a file with just DNS RRTYPEs is much easier, especially if you have 20 internal domains, as most universities seem to have :P Then you don't have to have duplicate keywords and/or ordening issues, and you wouldn't have large blobs in your config file. It is just much easier to create and maintain this in dig command output, so DNS presentation format. > Presentation format includes things like comments, newlines, > whitespace etc. > That is the reason I do not like to have presentation format inside > the binary wire formats like IKE. We do not need to do string parsing, > or regex processing in IKE library, but to properly parse presentation > format you need to do that. I think you can do this without regexp Tero :) > going to be in the presentation format. I think most people do use > configuration formats like: > > modecfgdns1=1.2.3.4 > modecfgdns2=8.8.8.8 > modecfgdomain1=example.com > modecfgtadnsseckeytag1=1270 > modecfgtadnssecalg1=8 > modecfgtadigesttype1=1 > modecfgtadigestdata1=506AD3A656... This would be terrible to generate from live DNS output. Much harder than "dig ds example.com @internalDNS > dns.txt" > Yes. This is needed. I would actually also would like to have text > explaining can you have comments whitespace, newlines etc inside the > Digest Data or not too, while we are at it. I would expect that most > of the implementations would not necessarely like those and sending > those over the wire is just wasting bytes. I'm confused what you are suggesting here. You say it should support the crazy stuff but then suggest implementations will just not support the crazy stuff? >>> and so on, instead of: >>> >>> INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E) It would be: INTERNAL_DNSSEC_TA("1270 8 1 0x506AD3A656D14D924655877628FFD6A98D7A847E") Note that here the domain name is not even part of the data. If you were sending presentation format, it would be nicer: INTERNAL_DNSSEC_TA("example.com. IN DS 1270 8 1 0x506AD3A656D14D924655877628FFD6A98D7A847E") And there would be no ordering constraints for INTERNAL_DNSSEC_TA() needing to immediately follow INTERNAL_DOMAIN() Paul From nobody Tue Nov 20 07:14:17 2018 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 7FAEF1286E3; Tue, 20 Nov 2018 07:14:15 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 J_wjjvNckiNb; Tue, 20 Nov 2018 07:14:14 -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 5C88E12D4F2; Tue, 20 Nov 2018 07:14:14 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42zq445RnlzL8Y; Tue, 20 Nov 2018 16:14:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542726852; bh=j9upps1QBoMULWL/w9Nl89F5kPTZ9K6jgeuPEBbKn3Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DhJntbCHzozgi2i17KwTO0xygKJXzMCGloksclGT2yYVFK0XVoXW/5FmtwI7sknuj HFBoW2s5+hA5LXk8M1F2Si5aPlcaYhpK4zDH1qMyvj0KbpUeTiKebbpfFvp0JLrPUz NgWAcR00un9JjzW2qL+2di2C+Y4bxRB4eGtE4OJ4= 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 EF48xHXtH_-q; Tue, 20 Nov 2018 16:14:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Nov 2018 16:14:11 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 98A7D4AA4C6; Tue, 20 Nov 2018 10:14:10 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 98A7D4AA4C6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8B45441C3B2D; Tue, 20 Nov 2018 10:14:10 -0500 (EST) Date: Tue, 20 Nov 2018 10:14:10 -0500 (EST) From: Paul Wouters To: Rafa Marin Lopez cc: Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 15:14:15 -0000 On Mon, 19 Nov 2018, Rafa Marin Lopez wrote: >> Based on the introduction and abstract of the draft, this document does two things: >> >> 1) Specify a yang model for use with SDWAN + IKE + IPsec >> 2) Define the desired modes and algorithms to use with 1) >> >> It does not try to map the entire IKE/IPsec IANA registry into a yang model. Let me know if this is incorrect, because I use >> this as an assumption for the remainder of the review. > > We must say that our I-D specifies 1) but being SDWAN one of the possible scenarios to operate so that the intent was to map the IKE/IPsec IANA registry. In any case we can change that approach if the WG consider is the right way to proceed. Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD or MUST (and not include MUST- or SHOULD-) So if any other new uses are defined, they don't try to use obsoleted or decayed algorithms. Paul From nobody Tue Nov 20 07:50:51 2018 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 E1A7D130E7C for ; Tue, 20 Nov 2018 07:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 OJ5KvXueGrKG for ; Tue, 20 Nov 2018 07:50:42 -0800 (PST) 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 8C43A130E8D for ; Tue, 20 Nov 2018 07:50:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C94D20089 for ; Tue, 20 Nov 2018 10:50:36 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A9ED6E32; Tue, 20 Nov 2018 10:50:40 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A958DE30 for ; Tue, 20 Nov 2018 10:50:40 -0500 (EST) From: Michael Richardson to: "ipsec\@ietf.org" In-Reply-To: <4812.1542724407@localhost> References: <154233104861.10051.7593212496190352066.idtracker@ietfa.amsl.com> <23537.18848.15817.35029@fireball.acr.fi> <23539.58882.139191.731005@fireball.acr.fi> <4812.1542724407@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 15:50:50 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: >> Presentation format includes things like comments, newlines, >> whitespace etc. >> That is the reason I do not like to have presentation format inside >> the binary wire formats like IKE. We do not need to do string parsing, >> or regex processing in IKE library, but to properly parse presentation >> format you need to do that. > +1 > For all the reasons you cited. > (Mind, I think split-horizon dns is perpetuation of a bad idea from 1989. > Unrouted IPv6 for internal use has no split-dns needs, so I don't really > care if gateway's will find a way to attack client systems.) To be clear: I acknowledge that I'm in the rough. My comments should not be intended to be seen as blocking. -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv0LVAACgkQgItw+93Q 3WXlfAf+PsV+MQji6SLljycsOMD9Ls+a9KUCup+8T7BE8aNuoYYYzoPBv4WKXFqD t2vZrI4NS85kebTNJ8vpxm8FKFV5r/8Oghf+GdtsMUO9PAwVSqENdYOh5DjjDyd/ psXsN402XWM8JpWsL4aEU/2ECUyAHMThinP9FkBmazQgPvXo3gsGpWqTL3qvwZFj KRgV7OXCI8wmyr92tdukCr6LAXRIZO3+c4ebLmoHpmihJsiX7rgeWIL1f9MbECa3 rm13AwhuuPId/hd+8mkBRcI1LUPx9W+K1a1TyJly+nBh9R3U4DQxAmb3JuF9792f HShwFXAQvq+Kj8UrGQcgFiBapGdFJA== =4hTT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 20 09:55:02 2018 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 83382130DCD; Tue, 20 Nov 2018 09:54:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mkOZZ4K6X0GR; Tue, 20 Nov 2018 09:54:50 -0800 (PST) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 79B5D1277BB; Tue, 20 Nov 2018 09:54:50 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id u9-v6so2953171wrr.0; Tue, 20 Nov 2018 09:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXN8rOibksqbLHVsOOVizy+ZM/B8D61ik9q5V9Q6uWc=; b=UYPACf+UydALWzhKYWEal4H3qMrIv2vBLhGwiI+C7yzi58ZlrfMF9ZUqhQdx14BZg+ kvWGcl1LOvQIJpY2PT4wKOthkxkroHOxcsnrHjRbr7LgHRR3vSvfngNoTTYbpwW6iaE9 B3QtVAXBhZjQl5vT/kKjFwPUaY57B9T3swbzSZQmpVjRlby6yq1gF9CDwQJmH54D4Zyz /Y2znbI4vt8XDECTLGv9YOPZtiROOeOGkTtDL3HfrOmv0LgKSxB3Z0qT1voJnTWnTyNn 29RCoLmkjYQQmaV3rNg4k87h+vraLF60vF07SKC310Maez6PxkDqyrx+bqQLvrdhHOQy 8oAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXN8rOibksqbLHVsOOVizy+ZM/B8D61ik9q5V9Q6uWc=; b=HWEuCsHU52aOIxDSiHWzTXc0F3Ux6F3oPAsM276tTVC3kCsfXLfj7opJ2HTx32RZIq T9yGeltCMggdO3W1hZX4IJdYcZlTDWjk5uSOFPBkvmL0g2IZPbMfApmtMbKHsEr5Dxhj RLcRPs3ju1UPv1RnHvnvVwFMPK7GpmmicFJC5aVDB2fGWeSqAqgS7DSb8IWyCfzB0mx0 PAaWTcwP9zBUM+krunzxOsWON50RDgPk7tz4IjTyK/rttUMRfW+HaZffjyRXEry/Omr6 pPIBsR6vKw2N0HTd4DnGu9n00CERAXB+ltuponB6zH9Z7oAy76V/l7ofKML/5EFP0+tK q2uQ== X-Gm-Message-State: AA+aEWYH3iGKUsRqqiic5KhtcsV3qExIG3bfmyDyooV42WJQjOEVe3kM ckVIoCz1rXW4O/m2qbvO/Ds= X-Google-Smtp-Source: AFSGD/WQOVqEZ8dN5Gv0H9Vc67llD19GFlrq0VQpULzdkZc3KMJo4RZPWqHl6gmsi8sLynk3J684kg== X-Received: by 2002:adf:a599:: with SMTP id g25-v6mr2985519wrc.188.1542736488941; Tue, 20 Nov 2018 09:54:48 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z17sm20860552wrv.2.2018.11.20.09.54.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 09:54:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Yoav Nir In-Reply-To: Date: Tue, 20 Nov 2018 19:54:45 +0200 Cc: Rafa Marin Lopez , i2nsf@ietf.org, "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> To: Paul Wouters X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 17:54:53 -0000 > On 20 Nov 2018, at 17:14, Paul Wouters wrote: >=20 > On Mon, 19 Nov 2018, Rafa Marin Lopez wrote: >=20 >>> Based on the introduction and abstract of the draft, this document = does two things: >>>=20 >>> 1) Specify a yang model for use with SDWAN + IKE + IPsec >>> 2) Define the desired modes and algorithms to use with 1) >>>=20 >>> It does not try to map the entire IKE/IPsec IANA registry into a = yang model. Let me know if this is incorrect, because I use >>> this as an assumption for the remainder of the review. >>=20 >> We must say that our I-D specifies 1) but being SDWAN one of the = possible scenarios to operate so that the intent was to map the = IKE/IPsec IANA registry. In any case we can change that approach if the = WG consider is the right way to proceed. >=20 > Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD > or MUST (and not include MUST- or SHOULD-) >=20 > So if any other new uses are defined, they don't try to use obsoleted = or > decayed algorithms. >=20 Hi, Paul. While I agree with your conclusion (although I think it=E2=80=99s fine = to include the single MUST- which is HMAC-SHA1), this is not really a = new application. It=E2=80=99s more like a new control plane for the old = VPN application. The typical implementation for the NSF in the ipsec-flow-protection = draft will be running on a machine that has an IPsec and potentially IKE = implementation. The authors=E2=80=99 own implementation is running on = top of the Linux kernel (and StrongSwan). If I was still working for an = IPsec vendor, I would implement this as a new usermode process pushing = SAs or policy into the kernel and into the VPN daemon.=20 So this isn=E2=80=99t like TLS 1.3 where you=E2=80=99ll need to upgrade = the TLS implementation anyway to get TLS 1.3, and the new crypto will = just come in the same package. The NSF code can be made to run on top of = a 10-year-old software implementation or 10-year-old hardware from = before AES-GCM existed. Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old = Linux can work, which is why I agree with your conclusion, except for = the tweak that MUST- is also OK. Yoav From nobody Tue Nov 20 13:45:27 2018 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 D8DE9128BCC; Tue, 20 Nov 2018 13:45:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 13:45:14 -0800 Archived-At: Subject: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 21:45:15 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains SHOULD be sent to the regular external DNS server. DNS queries for other domains might not be sent to the regular external DNS server? I'm thinking of one, but I'm flat-out guessing. From nobody Tue Nov 20 14:06:46 2018 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 BCA86130E4A; Tue, 20 Nov 2018 14:06:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275159776.29869.17358188603714912679.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 14:06:37 -0800 Archived-At: Subject: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 22:06:38 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding what the INTERNAL_DNSSEC_TA bit does - please help allay my fears... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? From nobody Tue Nov 20 14:20:20 2018 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 6F9E9130E41; Tue, 20 Nov 2018 14:20:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275241245.29803.13710690866636967430.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 14:20:12 -0800 Archived-At: Subject: [IPsec] Suresh Krishnan's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 22:20:12 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Sections 3.1 and 7 I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute would ever be zero. Do you expect someone to send an empty attribute? If not, the attribute definition should be updated in Section 7. * Meta comment Since the draft needs and uses a lot of example domain names, I would suggest using a reserved TLD (e.g. ".example") from BCP32 to build up the examples instead of using registered domain names. From nobody Tue Nov 20 14:30:07 2018 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 9ABE9130E5D; Tue, 20 Nov 2018 14:29:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275299762.29937.16511136271157489617.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 14:29:57 -0800 Archived-At: Subject: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 22:29:59 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? From nobody Tue Nov 20 14:30:13 2018 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 51689130E5B; Tue, 20 Nov 2018 14:29:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 14:29:59 -0800 Archived-At: Subject: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 22:29:59 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? From nobody Tue Nov 20 19:32:04 2018 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 D93B4130DE4; Tue, 20 Nov 2018 19:31:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154277111688.29795.6530139565050540963.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 19:31:56 -0800 Archived-At: Subject: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 03:31:57 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved via the private DNS servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? (I've known some IT managers who would think that was a fine idea.) §6: "the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity" How does a client determine the connections are part of the same logical entity? I can think of some ways, but I think the draft should be give some explicit guidance. From nobody Tue Nov 20 19:59:53 2018 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 CF300130E79; Tue, 20 Nov 2018 19:59:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154277279083.29769.12251386687781208754.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 19:59:50 -0800 Archived-At: Subject: [IPsec] Terry Manderson's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 03:59:51 -0000 Terry Manderson has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client MUST be in the administrative control of the VPN provider (I'm not sure I read that in the draft) might be one way out, yet I wonder if this is a case of simply having to trust that the VPN provider does the right thing (as cold as that leaves me) regardless of the words in the document. From nobody Tue Nov 20 21:01:54 2018 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 5B322130ED4; Tue, 20 Nov 2018 21:01:47 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 VOANIIPb85gt; Tue, 20 Nov 2018 21:01:45 -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 520D7130EBB; Tue, 20 Nov 2018 21:01:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4309Qv6BDDzLDP; Wed, 21 Nov 2018 06:01:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542776503; bh=TMPpiFIKXbzdMiLwVIf4+sMnzZb2yyET4ZLfcsRxMzU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QYASEe4Bb5ePJUJ/7pAVpu674RRa7NTIPlhKocHomwI4HTMqnGNWg721F2RFglkj2 PHEXVgntw00BRFm2yiOV6rLnWMNG+w6xKiMH6NBmFL3LFdJADG+QI1y1z4i6JlFLZx alKgDd5sTscPmekmLTVFIm6WbxTQC92WkU8XxO+Y= 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 rW6di9AfNZLO; Wed, 21 Nov 2018 06:01:43 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:01:42 +0100 (CET) Received: from [IPv6:2001:44c8:4515:a4ba:a0bc:45c6:a04:dc31] (unknown [49.230.72.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A59713797AD; Wed, 21 Nov 2018 00:01:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A59713797AD Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: Date: Wed, 21 Nov 2018 12:01:36 +0700 Cc: i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez Content-Transfer-Encoding: quoted-printable Message-Id: <518FCE4E-FA6E-489B-AB1D-68D89097F194@nohats.ca> References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> To: Yoav Nir Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:01:47 -0000 > On Nov 21, 2018, at 00:54, Yoav Nir wrote: >=20 > Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linu= x can work, which is why I agree with your conclusion, except for the tweak t= hat MUST- is also OK. Okay, if one of the expected deployments is 10 year old ikev2 code, then we s= hould add AES-CBC. I don=E2=80=99t know of any ikev2 code not supporting SHA= 2, so I would still suggest to leave SHA1 behind. Paul From nobody Tue Nov 20 21:22:39 2018 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 54E61130EDF; Tue, 20 Nov 2018 21:22:38 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 lj9w9ljwqef1; Tue, 20 Nov 2018 21:22:36 -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 1F79F128C65; Tue, 20 Nov 2018 21:22:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4309ty2hgmzLDW; Wed, 21 Nov 2018 06:22:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542777754; bh=u8wAA/DUOjh0z0yshTODNZcpeItzpdemOFaIl2P/seM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NRe3Dw5YR23YCC65UR80/+vbHU/TqYLePGF4PJkk6bGY2mMud4Yr5a/BdWFqzLLNH sEKwEv6sMa3kWYGAz9ZZTHR3KOjKND08jEvhtrHcPd1JQ4oxLzJVsIPeFMqLSVS+CI RJY6b5VLzDJi/n4TZDBIR0qL8DwuvjacQZ3QBH4M= 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 J7SPxeqVB9Vl; Wed, 21 Nov 2018 06:22:32 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:22:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 90EC23797AD; Wed, 21 Nov 2018 00:22:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 90EC23797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8172241C3B2E; Wed, 21 Nov 2018 00:22:30 -0500 (EST) Date: Wed, 21 Nov 2018 00:22:30 -0500 (EST) From: Paul Wouters To: Warren Kumari cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> Message-ID: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:22:38 -0000 On Tue, 20 Nov 2018, Warren Kumari wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I hope I'm just missing something obvious here, but this seems like it may > cause a significant security issue. No, you missed something subtle that clearly needs to stand out more :) > What is to stop one of these VPN providers setting: > INTERNAL_DNS_DOMAIN(www.paypal.com) > INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) > > or, better yet: > INTERNAL_DNS_DOMAIN(com) This sentence: When only a subset of traffic is routed into a private network using an IPsec SA, these Configuration Payload options can be used to define which private domains are intended to be resolved through the IPsec connection without affecting the client's global DNS resolution. I think we had more explicit text in earlier versions that didn't make the cut on future revisions. I will re-add proper text in Section 4 and the Security Section. > and so being able to spoof DNSSEC for paypal.com / all of .com? > This is especially worrying if something like DANE is ever deployed... There is a whole section on that. https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14#section-5 Specifically: IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains that can be updated out of band. IKE clients with an empty whitelist MUST NOT use any INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- whitelisted domain as an indication that their local configuration may need to be updated out of band. We basically said this is too dangerous to only authenticate via IKE. So now, you need to _also_ do a (remote) configuration update, which presumbly involves some Enterprise management system or humans. > The draft *does* says: > "Other generic or public domains, such as top-level domains, similarly SHOULD > NOT be whitelisted." - this doesn't really answer the above. 1: It is > increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: > How do I programatically tell if www.foo.net is a "public domain"? What is a > public domain anyway? How is an implementer supposed to address this? What we tried to say was that any generic domain open for any registrant for registration should never be accepted. While if you are Red Hat, maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree that it is difficult to determine this. The idea of the whitelist is that VPN clients will show/confirm/enable the listed DNS domains, so that if Honest Paul's VPN service includes "gmail.com", the enduser can freak out properly. > It also says: > "Any updates to this whitelist of domain names MUST happen via explicit human > interaction to prevent invisible installation of trust anchors." Is my auntie > really expected (or competent) to understand what "Your VPN provider, TrustVPN > wants to whitelist com. Do you want to allow this? [Y/N]" means? Split-DNS is meant for Enterprise use of actual domains. If your auntie works for Foo Inc., hopefully she can either have Foo's sysadmin configure and install her VPN, or if the admin gives her some kind of profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants to whitelist internal.foo.com" and she would be familiar with using the internal.foo.com domain from the office. Note that our text basically meant to say the IKE software should probably never allow com/net/org/CCtld ever, but that would be difficult to hardcode because we _still_ haven't fixed the PublicSuffix issue :/ > Also, some of the DNS behavior is handwavey - I think that the document really > should be reviewed by DNSOP, but will leave it to Eric to make that call. What is wavey? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be > passed to another (DNS) program for processing. As with any network > input, the content SHOULD be considered untrusted and handled > accordingly." feels a bit handwavey. Are there currently any DNSSEC > validating clients which can easily take a targeted TA for a specific domain > / set of domains? > > I’m also not quite sure how this interacts with delegations. E.g: > > example.com 600 IN NS ns01.internal.example > And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local > recursive, does it need to send the query to ns01 though the VPN or not? It should not think about "through the VPN or not". We had that text originally, but Tero pointed out a lot of Enterprise VPN's can come up on demand. So the initial IKE negotiation could be for 10.1.2.3/32, and include the DNS configuration for the internal auth servers on 192.168.1.1. It needs to configure the DNS so a packet for 192.1.1:53 triggers another IPsec tunnel to be setup. So to use an unbound example, you only need to drop in the internal DS record, and the "unbound-control forward example.com ip1 ip2" configuration pointing to the internal auth servers for example.com. Paul From nobody Tue Nov 20 21:25:57 2018 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 9A4D6128C65; Tue, 20 Nov 2018 21:25:46 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 H6ngxOZYObn7; Tue, 20 Nov 2018 21:25:45 -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 2BE8A12007C; Tue, 20 Nov 2018 21:25:45 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4309yZ5xkJzLDZ; Wed, 21 Nov 2018 06:25:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542777942; bh=KMDLoAQbL4GvPa6uPI29ecScMbHqoTzT1XEqDX5AEsU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=APYpzRTUE6JeWQhOA4TiMHHH05F0PvMcLiSnPv9c4pRqYBYPyT62djboFMe7bqyOL 0FgBJXG2VCbptPQjNQxcQy7MtYip/4f3VgiBZzd0QR0ZYXKcWNeLArw3tRuetcsAHe mvsC7+Ye3ozqBEZL0Dsn48rBwFb3Y7BHajmv/2U8= 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 yGjJqlppdkjm; Wed, 21 Nov 2018 06:25:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:25:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 22EA33797AD; Wed, 21 Nov 2018 00:25:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 22EA33797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 07C2841C3B2E; Wed, 21 Nov 2018 00:25:41 -0500 (EST) Date: Wed, 21 Nov 2018 00:25:40 -0500 (EST) From: Paul Wouters To: Suresh Krishnan cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154275241245.29803.13710690866636967430.idtracker@ietfa.amsl.com> Message-ID: References: <154275241245.29803.13710690866636967430.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Suresh Krishnan's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:25:47 -0000 On Tue, 20 Nov 2018, Suresh Krishnan wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Sections 3.1 and 7 > > I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute > would ever be zero. Do you expect someone to send an empty attribute? If not, > the attribute definition should be updated in Section 7. If the initiator has no domains listed, it can send a zero-length attribute to indicate support for this feature. The responder can then decide to include INTERNAL_DNS_DOMAIN replies (non-zero). or perhaps even indicate support, but no configured domains, with a zero length reply. > Since the draft needs and uses a lot of example domain names, I would suggest > using a reserved TLD (e.g. ".example") from BCP32 to build up the examples > instead of using registered domain names. Yes, others have made similar comments and I will make the changes. Paul From nobody Tue Nov 20 21:32:28 2018 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 CBE10130F8A; Tue, 20 Nov 2018 21:32:17 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 6KmNiVXVRWzi; Tue, 20 Nov 2018 21:32:14 -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 D3F9E130F3F; Tue, 20 Nov 2018 21:32:11 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430B621vGkzLDZ; Wed, 21 Nov 2018 06:32:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542778330; bh=5v4qggpEhz8Iv9sWbhT3hp8250J0mHeDnNXfmVBU2ts=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sK+ZMJGYjmpKNJnS6GBjKuFu723vlpmsyWTCocPBWVOsmSg5xDXG8TXjutAQTACDK Kjipv56RsL4VA04083WUkkOTCnmbfwtymEB991lP8NqjY9JyjhB4+1kF9ADcE1qORB vp9fb9JCrPaTHwRrL2F7ia0XIEt5Ir3N8K/tGCHM= 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 RJ-jYIHaHYGj; Wed, 21 Nov 2018 06:32:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:32:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 67E093797AD; Wed, 21 Nov 2018 00:32:08 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 67E093797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A37941C3B2E; Wed, 21 Nov 2018 00:32:08 -0500 (EST) Date: Wed, 21 Nov 2018 00:32:08 -0500 (EST) From: Paul Wouters To: Spencer Dawkins cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> Message-ID: References: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:32:18 -0000 On Tue, 20 Nov 2018, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Perhaps it would be helpful to give an example of why > > A client using these configuration payloads will be able to request > and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN > and INTERNAL_DNSSEC_TA configuration attributes. The client device > can use the internal DNS server(s) for any DNS queries within the > assigned domains. DNS queries for other domains SHOULD be sent to > the regular external DNS server. > > DNS queries for other domains might not be sent to the regular external DNS > server? I'm thinking of one, but I'm flat-out guessing. I think you are right, and we are mixing up INTERNAL_IP4_DNS with INTERNAL_DNS_DOMAIN. the idea is that the client can decide to not only use some authoritative internal servers, but also use some recursive internal servers. But I think those should be specified in the exiting INTERNAL_IP4_DNS / INTERNAL_IP6_DNS attributes. I suggest we change the above to: A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains MAY be sent to an internal recursive DNS server specified in an INTERNAL_IP4_DNS or INTERNAL_IP6_DNS Configuration Payload but MAY also be resolved using the client's regular DNS resolving mechanisms outside of the IPsec connection. Tommy, let me know what you think about this change? Paul From nobody Tue Nov 20 21:41:45 2018 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 73DB6130EE2; Tue, 20 Nov 2018 21:41:37 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 SBYRmY_GQt3j; Tue, 20 Nov 2018 21:41:36 -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 B7C5D124C04; Tue, 20 Nov 2018 21:41:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430BJt0TKGzLDb; Wed, 21 Nov 2018 06:41:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542778894; bh=8mpKmM6Aou6Ji+DgJwL/R6QT3wHRCWaoT529pGGGSZY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hmE7BZ8v6NZsthOU0Xl1YDLWTgQjtKqr1fDloTf79c241IAU3gJ1qMhui7MhmGD+t lV4UQOGcxT90hEfSboTmXK/XlQr9qKGeUcKP5aMzR+UNbEyU+rx0bRpIzpUaqEyuSK wf0AuXA8vSEMOinKjSi1+0L41lOKnuH1RZmnuRTw= 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 l_dsxj0XOl9z; Wed, 21 Nov 2018 06:41:32 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:41:32 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 228063797AD; Wed, 21 Nov 2018 00:41:31 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 228063797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 150DC41C3B2E; Wed, 21 Nov 2018 00:41:31 -0500 (EST) Date: Wed, 21 Nov 2018 00:41:31 -0500 (EST) From: Paul Wouters To: Terry Manderson cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154277279083.29769.12251386687781208754.idtracker@ietfa.amsl.com> Message-ID: References: <154277279083.29769.12251386687781208754.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Terry Manderson's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:41:37 -0000 On Tue, 20 Nov 2018, Terry Manderson wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the time and effort invested in this document. I'm also very > interested to see the resolution to Warren's DISCUSS regarding > ipsecme-split-dns being used as an easy tool to over-claim entire sections of > the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client > MUST be in the administrative control of the VPN provider (I'm not sure I read > that in the draft) might be one way out, yet I wonder if this is a case of > simply having to trust that the VPN provider does the right thing (as cold as > that leaves me) regardless of the words in the document. The defense mechanisms against that are (and I will clarify the text for that): 1) If there is no split-tunnel, then split-DNS payloads MUST be ignored. (this covers the third party VPN providers, but note those services can also specify INTERNAL_IPV4_DNS to take all your queries. Of course, they can see /modify all your packets that have no cryptogrpahic protection beyond the IPsec layer) 2) Don't accept TLDs (and/or wellknown SLDs) This might be easy for com/net/org, but harder for facebook.com or gmail.com) 3) Any DNSSEC trust anchor overrides MUST come in via the provisioning proces and NOT via the IKE protocol. It is step 2) that might require user interaction and is hard to do, but I do not think it is a solvable problem, and note that split-tunnel setups that require split-dns are typically enterprise deployments where you must trust the enterprise. There is some question about 1) being abused, eg offer 0.0.0.0/1 and 128.0.0.0/1 to trick the client into believing it is on split-tunnel even though it is not, but we feel any VPN actor being that malicious can do more evil things secretly after decrypting your traffic anyway, such as a transparent proxy for port 53. That is why we allow INTERNAL_DNS_DOMAIN without the provisioning step, but do not allow INTERNAL_DNSSEC_TA without it being provisioned outside of IKE. Paul Paul From nobody Tue Nov 20 21:47:33 2018 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 B2691124C04; Tue, 20 Nov 2018 21:47:23 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 6hQMjgXuNfRz; Tue, 20 Nov 2018 21:47:21 -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 A292A12D4E6; Tue, 20 Nov 2018 21:47:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430BRX1qS0zLDZ; Wed, 21 Nov 2018 06:47:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542779240; bh=3vefl8zIbUgUSq4RP7vG1Ous4DVuFuxC+q8yj3nmLhA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Y8L6kcs47lcuH3s2d9MINYbNmBvSdhJKsATn7CL4pJHti9b3K4EbPu/rggAZN4aN5 qFRZCS24o6R+RVsoJfc6EY6slwtos9AC97BiKO+VxFjsWERU+1BQ89hdq0ZXxdmTVI tMFV4F8uCAPJjhURCOoSt4Wdck/BLD6mS7Cw3NBo= 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 HY9JAt04LBAs; Wed, 21 Nov 2018 06:47:18 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 06:47:18 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EEDE43797AD; Wed, 21 Nov 2018 00:47:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EEDE43797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E2EB941C3B2E; Wed, 21 Nov 2018 00:47:17 -0500 (EST) Date: Wed, 21 Nov 2018 00:47:17 -0500 (EST) From: Paul Wouters To: Ben Campbell cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154277111688.29795.6530139565050540963.idtracker@ietfa.amsl.com> Message-ID: References: <154277111688.29795.6530139565050540963.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 05:47:24 -0000 On Tue, 20 Nov 2018, Ben Campbell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - General: Once my client signals support for split DNS, what prevents a server > from over claiming the domains that should be resolved via the private DNS > servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? > (I've known some IT managers who would think that was a fine idea.) Nothing prevents that. Just like they can run a transparent proxy on port 53 to accomplish the same. When you install a split-tunnel VPN, you place some trust in those enterprise administrators (forced or not) Local policy might of course prevent it. Libreswan allows a client to configure modecfdomains="redhat.com ibm.com" and when connected would not send any DNS queries for catpictures.com to the internal DNS even if the VPN server response contained an INTERNAL_DNS_DOMAIN for catpictures.com. > §6: "the IKE connection SHOULD only process > the DNS information if the two connections are part of the same > logical entity" > How does a client determine the connections are part of the same logical > entity? I can think of some ways, but I think the draft should be give some > explicit guidance. I think that would be very vendor specific. Some vendors might have hierarchical structures so "Red Hat" can have two VPN connections, others might just do it based on the same remote VPN server ID (eg vpn.redhat.com) I'll add some text similar to this. Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Nov 20 22:03:51 2018 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 E2340130EDF; Tue, 20 Nov 2018 22:03:49 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 7EMiaRPHYAgq; Tue, 20 Nov 2018 22:03:48 -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 0BBA712D4EA; Tue, 20 Nov 2018 22:03:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430BpR4Sw1zLDZ; Wed, 21 Nov 2018 07:03:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542780223; bh=JmNt8n20kaLvQcG9x+8BHFYA1vt1euDmjeCj5ul7FjA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h+Ob69TOVAPQKYjO95BedUISih8ulJn0ycunP3UzPlgshYfquNZ9MvET8pXGehTFb 7deqqzxEiM9uqRsb0YcTgcV1nkggx0XSB/zJBZ3OwRN12zCjdMaovcjgJ03smXmOoe 2buwrvG4jjbVz4uWWsCQzFvPb/rSOlebAgPT+lIs= 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 FjyIv1wEw38F; Wed, 21 Nov 2018 07:03:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 07:03:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E796D3797AD; Wed, 21 Nov 2018 01:03:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E796D3797AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DDFEB41C3B2E; Wed, 21 Nov 2018 01:03:41 -0500 (EST) Date: Wed, 21 Nov 2018 01:03:41 -0500 (EST) From: Paul Wouters To: Alissa Cooper cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov In-Reply-To: <154265994634.16507.11786093943228748567.idtracker@ietfa.amsl.com> Message-ID: References: <154265994634.16507.11786093943228748567.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 06:03:50 -0000 On Mon, 19 Nov 2018, Alissa Cooper wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 5: > > "Enterprise Certificate Agency" --> I would have expected this to say > Enterprise Certificate Authority. Your expectation is correct :) I will fix. > "Other generic or public domains, such as top-level domains, similarly SHOULD > NOT be whitelisted." Under what exceptional circumstances would it make sense > to whitelist a TLD? Is this like if I run Example Corp and I own .example? Exactly. Or if you would use .internal or if Warren gets his way .alt :) Paul From nobody Tue Nov 20 22:14:47 2018 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 05F0812D4EA; Tue, 20 Nov 2018 22:14:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UmqnY2BvEZrj; Tue, 20 Nov 2018 22:14:43 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 881E81277BB; Tue, 20 Nov 2018 22:14:43 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id u6so3913515plm.8; Tue, 20 Nov 2018 22:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xp5HPlB5HWKMwELq9ZnlghQc2itH0OYKDgyqdOi/Bzc=; b=tEbGbP5SVqgZBEvdq3+pKEtDylQy/wQ1q1+PGBG2UobyavrHqPZv6lYVIebpLqEG+Q 2kFfd0UtGWxDsOOV5RQX5qGmFtbiZe+1fUyYqAMKRz2V3k0z3FBAUPHwMe60vUtHdCk/ clU7nSpQXrCwAqkC1t+J3VdetkexoQQl51AwcAJVUdVJ9XkqclRXa6ODdR1eghNrCAXo OKpQpxL1xEbJ9AIcq6fRZLnNnG6bmaKA2mTxf9llvevUC7KS/GPee4YxdY/ImZs4N+Zl CBCmTchht9VGW+F4plb0DSmXLvbmPS9NoGhS3hOlyuOt5HyRkNciav70onxk6O993vzB dbAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xp5HPlB5HWKMwELq9ZnlghQc2itH0OYKDgyqdOi/Bzc=; b=Gi1gN0CDmP+6qg2isbGO5YYNGp511h/P+Bj6oDkdsW3OXT6Tcu7nC8LSwzpabxjwg0 T66fwi97ApIq8ExzZ6Zjb0MnwkuBlMSSO0H6z0bQyiRr/yNP2OPZ/WXJGrO3NyXoSJOh 5eFyu8vGpgqaKD7TriHbSdQA71qNAnQVFIL55dbpI6TnA7aECzw1+drBkcsHXIl1czNM Mh952sxbQtQ9Sf8BDc9ope+9eKpn5Yslvu0mWzQKZZ81rYJkI2Iho0gCyTJD6Ccm4Clg Yxr6Ha9rluH0QHqe73p+BRO92K5j+uYnN0OY7antkn5J2wWYC+QFFdJHvg5i0EpBZtCa UqeA== X-Gm-Message-State: AA+aEWaoiMzQgL8uDV3QHbgKqKrpkFUsED4awhTb9A2F9d5GbDpemuZ8 xIXumemq5O/jF/yAvR8YoFvWajP/385q67QHyfQ= X-Google-Smtp-Source: AFSGD/XbysLipVuFELPbaKR6r7kJ8UqOd+6WghirqxI3vNFuB4zONJqKH1Dg153/qmo6x/b/wetuJWTETbxyqXkVy1s= X-Received: by 2002:a17:902:7088:: with SMTP id z8-v6mr5193157plk.329.1542780882935; Tue, 20 Nov 2018 22:14:42 -0800 (PST) MIME-Version: 1.0 References: <154275241245.29803.13710690866636967430.idtracker@ietfa.amsl.com> In-Reply-To: From: Suresh Krishnan Date: Wed, 21 Nov 2018 01:14:30 -0500 Message-ID: To: Paul Wouters Cc: Suresh Krishnan , ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, The IESG , draft-ietf-ipsecme-split-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000007e6219057b26aa3a" Archived-At: Subject: Re: [IPsec] Suresh Krishnan's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 06:14:45 -0000 --0000000000007e6219057b26aa3a Content-Type: text/plain; charset="UTF-8" Hi Paul, On Wed, Nov 21, 2018, 12:25 AM Paul Wouters wrote: > On Tue, 20 Nov 2018, Suresh Krishnan wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > * Sections 3.1 and 7 > > > > I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN > attribute > > would ever be zero. Do you expect someone to send an empty attribute? If > not, > > the attribute definition should be updated in Section 7. > > If the initiator has no domains listed, it can send a zero-length > attribute to indicate support for this feature. The responder can then > decide to include INTERNAL_DNS_DOMAIN replies (non-zero). or perhaps > even indicate support, but no configured domains, with a zero length > reply. > That makes sense. Thanks for clarifying. > Since the draft needs and uses a lot of example domain names, I would > suggest > > using a reserved TLD (e.g. ".example") from BCP32 to build up the > examples > > instead of using registered domain names. > > Yes, others have made similar comments and I will make the changes. > Excellent. Regards Suresh --0000000000007e6219057b26aa3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,=C2=A0

On Wed, Nov 21, 2018, 12:25 AM Paul Wouters <paul@nohats.ca> wrote:
On Tue, 20 Nov 2018, Suresh Krishnan wrote:

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> * Sections 3.1 and 7
>
> I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN at= tribute
> would ever be zero. Do you expect someone to send an empty attribute? = If not,
> the attribute definition should be updated in Section 7.

If the initiator has no domains listed, it can send a zero-length
attribute to indicate support for this feature. The responder can then
decide to include INTERNAL_DNS_DOMAIN replies (non-zero). or perhaps
even indicate support, but no configured domains, with a zero length
reply.

That makes sense. Thanks for clarifying.=C2=A0

> Since the draft needs and uses a lot of example domain names, I would = suggest
> using a reserved TLD (e.g. ".example") from BCP32 to build u= p the examples
> instead of using registered domain names.

Yes, others have made similar comments and I will make the changes.

Excellen= t.=C2=A0

Regards=C2=A0
Suresh
--0000000000007e6219057b26aa3a-- From nobody Wed Nov 21 02:51:47 2018 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 92EF1130DC5; Wed, 21 Nov 2018 02:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=cooperw.in header.b=qOfTS1/1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZEF429od 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 P2B9WcGjb0qz; Wed, 21 Nov 2018 02:51:37 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D7A12F1A2; Wed, 21 Nov 2018 02:51:37 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4F848220B3; Wed, 21 Nov 2018 05:50:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 21 Nov 2018 05:50:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=j 9GQCzwmpnwtFqaOnKKilcV3WcY1vXX3+UWpmGUDzoo=; b=qOfTS1/1AD6lNfRAJ oBB/veo0Sr3/q1p+FuH/4F5Ob+iMNp0WQ5NAI/iouRSwWrkZ+XbyGK51Lcg33TTE mY4wRjzvFyDb6CzCVPaj/rjObZ47QQQ6nDOYpX84fANrayIwM1i5WWhQ/WTi6Z0g eD77X5RD17TH3b/F14gT0FNKqLbwOBELfM0tjuR02Ic6f4IymGtBSnM1wU7ioe8R U+F+Geqp3fiBJ4mk5b8AejE60cPMPZKVlKJaG7CdjXH+jHhwsc+8DPC4+gYtYd84 Api+0rYfuyiB/wittj1LmNj5wvwS/vS4/xzd0UzLpT0U/JR5BRxW36mD+o6HrR4y D/mmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=j9GQCzwmpnwtFqaOnKKilcV3WcY1vXX3+UWpmGUDz oo=; b=ZEF429odMTtTCfZcMpNHaLg5Z1UsXoGWkQMSYfwGGRHZcJwMrTjam3UOo Swg249UVkfQKUjKeVjK0/MZ6iewI0e6Vk2UDcyRMUWJTbmAVWOvbir29+5gUcKko rU8jdDpycmvU8m8T89RdGD4f9PC+fot/AzYEb6yTKq+LwqrOb8sPC5O+5cMK0bsb 5EQkE+B1iQm2DPy9eGIPFbZR5bwtizVYJFEx/yXkgWbOUEbbR5x7bwjWeBYf4dlg idwkq0gCw2SVD6FlCRPacwTDMGS1lNB0qc6zj8Xre6YneTNxbJHEEjr0pt4u9EgV 42fVFuJBtFukhfCK4uDMR/XQ8AfxA== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 4902DE49CA; Wed, 21 Nov 2018 05:50:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Wed, 21 Nov 2018 05:50:27 -0500 Cc: IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, david.waltermire@nist.gov Content-Transfer-Encoding: quoted-printable Message-Id: <8D0DBED8-D1B4-4FDE-82D4-DC4521C0E2A1@cooperw.in> References: <154265994634.16507.11786093943228748567.idtracker@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 10:51:40 -0000 > On Nov 21, 2018, at 1:03 AM, Paul Wouters wrote: >=20 > On Mon, 19 Nov 2018, Alissa Cooper wrote: >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 5: >>=20 >> "Enterprise Certificate Agency" --> I would have expected this to say >> Enterprise Certificate Authority. >=20 > Your expectation is correct :) I will fix. >=20 >> "Other generic or public domains, such as top-level domains, = similarly SHOULD >> NOT be whitelisted." Under what exceptional circumstances would it = make sense >> to whitelist a TLD? Is this like if I run Example Corp and I own = .example? >=20 > Exactly. Or if you would use .internal or if Warren gets his way .alt = :) Thanks. It might be worth giving an example or two in the document. Alissa >=20 > Paul From nobody Wed Nov 21 06:49:58 2018 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 35E1B127A8E; Wed, 21 Nov 2018 06:49:56 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Eyl_qgWnBwmc; Wed, 21 Nov 2018 06:49:53 -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 C4A72130F91; Wed, 21 Nov 2018 06:48:58 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430QSR2tyCzLFt; Wed, 21 Nov 2018 15:48:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542811735; bh=Ca2HeUbjoNnAyTuCd3vmY97E1Buhei8NIXpBsarJiqQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DcD8B+VMo+vA5AQyTuTlLaJl3ge/4qtq0f9FTUcr+2g8+FszKGM+B5YMeDfBCJakl HK37pPSo2LvMp1PHqrHIu1kZvLWXJl7V7HB57DCX7NZf8CBWuNYuP4T7coYOVZbXjc wTA/6TA/zHr0N0dMlMxvkxzjodmPjTDO3G3RHs3Y= 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 PLzVvVDXc95R; Wed, 21 Nov 2018 15:48:49 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 15:48:48 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4A55849ED70; Wed, 21 Nov 2018 09:48:47 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4A55849ED70 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 427F741C3B26; Wed, 21 Nov 2018 09:48:47 -0500 (EST) Date: Wed, 21 Nov 2018 09:48:47 -0500 (EST) From: Paul Wouters To: Spencer Dawkins cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, The IESG , draft-ietf-ipsecme-split-dns@ietf.org In-Reply-To: Message-ID: References: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 14:49:57 -0000 On Wed, 21 Nov 2018, Paul Wouters wrote: > I think you are right, and we are mixing up INTERNAL_IP4_DNS with > INTERNAL_DNS_DOMAIN. > > the idea is that the client can decide to not only use some > authoritative internal servers, but also use some recursive internal > servers. But I think those should be specified in the exiting > INTERNAL_IP4_DNS / INTERNAL_IP6_DNS attributes. Actually, that does not work. The current specification does not allow a INTERNAL_IP4_DNS or INTERNAL_IP6_DNS to be associated with only some (or none) of the INTERNAL_DNS_DOMAINS. > I suggest we change the above to: > > A client using these configuration payloads will be able to request > and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN > and INTERNAL_DNSSEC_TA configuration attributes. The client device > can use the internal DNS server(s) for any DNS queries within the > assigned domains. DNS queries for other domains MAY be sent to > an internal recursive DNS server specified in an INTERNAL_IP4_DNS > or INTERNAL_IP6_DNS Configuration Payload but MAY also be resolved > using the client's regular DNS resolving mechanisms outside of the > IPsec connection. So I suggest instead: A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. These attributes MUST be accompanied by one or more INTERNAL_IP4_DNS or INTERNAL_IP6_DNS configuration attributes. The client device can then use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains MUST be sent to the regular DNS service of the client. Paul From nobody Wed Nov 21 07:00:52 2018 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 9DB28130DFD for ; Wed, 21 Nov 2018 07:00:44 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 h1fEfRehUkBL for ; Wed, 21 Nov 2018 07:00:41 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 BD93F124BF6 for ; Wed, 21 Nov 2018 07:00:36 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id u13-v6so6093778wmc.4 for ; Wed, 21 Nov 2018 07:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fiUwC/xOHzh3MbGOCsk15lPOoH9rVLNdDthmsOFLR2g=; b=axl+NAIAALsi1Ulm2RdolkC7NDfRXglVIUJzlN2WGL4p1k+1n4xiclXsCy6smqieOV w3RhfA/daxpbpbJmhLTSQgskOd4HirzB75cPdp2Z7vyoEjP/yFMpwetYLsqQtXgnuMxN MckrHOehbTkTxyfH8f9wjBHXG+2T6E+TaX75pvy8eJ3mp2eDIZ5B11KcWKegBymMNKIT QhA32Hat40VsPYvDb8clNw3a/9GJ5ojsw1szW9rqlUDf4VV9fOVdx0AVmwNy9erl0yAu YaNo//kYcc7apqd+T9lnCUtCNmeN5ehxgiQecDNiY3UlWI93s1vaTRxvC7uinX2G6uz1 KcLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fiUwC/xOHzh3MbGOCsk15lPOoH9rVLNdDthmsOFLR2g=; b=DHivU7+0i69Fh5uNdui4vuyUbhVH9YQ71K5TmwspAfSyAp9fw5AL6Vdd+d9+DYEGrl +idw+HOSh4UR8DIi759QtlyIXw9MQJW0BteYsoZOgSd81RLMZHBsxmB2WyJ5IxOMO2xt gsn1p0WvxkbyWSgY4Fw8JJh3VmxZKAGT5qlDv4SxBJ/5cSx4u6G1Kc1wEwm3+NKi61cQ kkni4gYx7MslLHIm1kARRFkajMVr4wwa5P7z/mukq2KgyadwMBXexOE5/x9fikddrvJg WnR/9GLk1Qbrm0rUvYlP+Njqc7Ha/POfcLUkvrojC8gjF4/GSSZssl+GX2LtBmZcnZDS m5Mw== X-Gm-Message-State: AGRZ1gL8PavQhOVHo/yyUERome0RdN7aEMiJPg2EUpi1tGHzcrLFxkUW x69jTgJ0+U2hlk6MNewzxBIbTWO0aYhjw0OoWTSpuQ== X-Google-Smtp-Source: AJdET5eZ5AalhNgkhR+n6E23PkzDMz/h7767FfWZRX9n7mM3b3P7v+R1twQP8dIZlMm5wdWst/vhfte66RWckI1E4JY= X-Received: by 2002:a1c:c701:: with SMTP id x1-v6mr6340821wmf.116.1542812434810; Wed, 21 Nov 2018 07:00:34 -0800 (PST) MIME-Version: 1.0 References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Wed, 21 Nov 2018 09:59:58 -0500 Message-ID: To: Paul Wouters Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Type: multipart/alternative; boundary="00000000000021dd39057b2e0365" Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 15:00:45 -0000 --00000000000021dd39057b2e0365 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2018 at 12:22 AM Paul Wouters wrote: > On Tue, 20 Nov 2018, Warren Kumari wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I hope I'm just missing something obvious here, but this seems like it > may > > cause a significant security issue. > > No, you missed something subtle that clearly needs to stand out more :) > > > What is to stop one of these VPN providers setting: > > INTERNAL_DNS_DOMAIN(www.paypal.com) > > INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) > > > > or, better yet: > > INTERNAL_DNS_DOMAIN(com) > > This sentence: > > When only a subset of traffic is routed into a private network using > an IPsec SA, these Configuration Payload options can be used to > define which private domains are intended to be resolved through the > IPsec connection without affecting the client's global DNS > resolution. > > I think we had more explicit text in earlier versions that didn't make > the cut on future revisions. I will re-add proper text in Section 4 and > the Security Section. > > > and so being able to spoof DNSSEC for paypal.com / all of .com? > > This is especially worrying if something like DANE is ever deployed... > > There is a whole section on that. > > https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14#section-5 > > Specifically: > > IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use > a whitelist of one or more domains that can be updated out of band. > IKE clients with an empty whitelist MUST NOT use any > INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY > interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- > whitelisted domain as an indication that their local configuration > may need to be updated out of band. > > We basically said this is too dangerous to only authenticate via IKE. So > now, you need to _also_ do a (remote) configuration update, which > presumbly involves some Enterprise management system or humans. > > > The draft *does* says: > > "Other generic or public domains, such as top-level domains, similarly > SHOULD > > NOT be whitelisted." - this doesn't really answer the above. 1: It is > > increasingly hard to know what is a "real" TLD (.internal? .bank? > .home?) 2: > > How do I programatically tell if www.foo.net is a "public domain"? What > is a > > public domain anyway? How is an implementer supposed to address this? > > What we tried to say was that any generic domain open for any registrant > for registration should never be accepted. While if you are Red Hat, > maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree > that it is difficult to determine this. The idea of the whitelist is > that VPN clients will show/confirm/enable the listed DNS domains, so > that if Honest Paul's VPN service includes "gmail.com", the enduser can > freak out properly. > > > It also says: > > "Any updates to this whitelist of domain names MUST happen via explicit > human > > interaction to prevent invisible installation of trust anchors." Is my > auntie > > really expected (or competent) to understand what "Your VPN provider, > TrustVPN > > wants to whitelist com. Do you want to allow this? [Y/N]" means? > > Split-DNS is meant for Enterprise use of actual domains. If your auntie > works for Foo Inc., hopefully she can either have Foo's sysadmin > configure and install her VPN, or if the admin gives her some kind of > profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants to > whitelist internal.foo.com" and she would be familiar with using the > internal.foo.com domain from the office. > Yes, I get that the *intended* audience is Enterprises, and that usage doesn't really scare me (most enterprise admins already have their fingers sufficiently deep inside their employees machines that they can do $whatever anyway). My concerns is that this will also be used for the "Buy our VPN for secure browsing of the torrentz - only $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type people -- I trust my enterprise admins to not DNSSEC / DANE poison me, but I don't necessarily trust (to pick at random) CyberGhostVPN - https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=3D1392&coupon=3DFl= ashSale2&aff_sub4=3DFlashSale2& (I know nothing about this org!) W > > Note that our text basically meant to say the IKE software should > probably never allow com/net/org/CCtld ever, but that would be difficult > to hardcode because we _still_ haven't fixed the PublicSuffix issue :/ > > > Also, some of the DNS behavior is handwavey - I think that the document > really > > should be reviewed by DNSOP, but will leave it to Eric to make that cal= l. > > What is wavey? > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This section: " The content of INTERNAL_DNS_DOMAIN and > INTERNAL_DNSSEC_TA may be > > passed to another (DNS) program for processing. As with any network > > input, the content SHOULD be considered untrusted and handled > > accordingly." feels a bit handwavey. Are there currently any DNSSEC > > validating clients which can easily take a targeted TA for a specific > domain > > / set of domains? > > > > I=E2=80=99m also not quite sure how this interacts with delegations. E.= g: > > > > example.com 600 IN NS ns01.internal.example > > And then INTERNAL_DNS_DOMAIN(internal.example) =E2=80=94 if the client = runs a > local > > recursive, does it need to send the query to ns01 though the VPN or not= ? > > It should not think about "through the VPN or not". We had that text > originally, but Tero pointed out a lot of Enterprise VPN's can come up > on demand. So the initial IKE negotiation could be for 10.1.2.3/32, and > include the DNS configuration for the internal auth servers on > 192.168.1.1. It needs to configure the DNS so a packet for 192.1.1:53 > triggers another IPsec tunnel to be setup. > > So to use an unbound example, you only need to drop in the internal DS > record, and the "unbound-control forward example.com ip1 ip2" > configuration pointing to the internal auth servers for example.com. > > Paul > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000021dd39057b2e0365 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 21, 2018 at 12:22 AM Paul Wouters = <paul@nohats.ca> wrote:
On Tue, 20 Nov 2018, Wa= rren Kumari wrote:

> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I hope I'm just missing something obvious here, but this seems lik= e it may
> cause a significant security issue.

No, you missed something subtle that clearly needs to stand out more :)

> What is to stop one of these VPN providers setting:
> INTERNAL_DNS_DOMAIN(www.paypal.com)
> INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)
>
> or, better yet:
> INTERNAL_DNS_DOMAIN(com)

This sentence:

=C2=A0 =C2=A0 When only a subset of traffic is routed into a private networ= k using
=C2=A0 =C2=A0 an IPsec SA, these Configuration Payload options can be used = to
=C2=A0 =C2=A0 define which private domains are intended to be resolved thro= ugh the
=C2=A0 =C2=A0 IPsec connection without affecting the client's global DN= S
=C2=A0 =C2=A0 resolution.

I think we had more explicit text in earlier versions that didn't make<= br> the cut on future revisions. I will re-add proper text in Section 4 and
the Security Section.

> and so being able to spoof DNSSEC for paypal.com / all of .com?
> This is especially worrying if something like DANE is ever deployed...=

There is a whole section on that.

https://tools.ietf.org/html/dra= ft-ietf-ipsecme-split-dns-14#section-5

Specifically:

=C2=A0 =C2=A0 IKE clients willing to accept INTERNAL_DNSSEC_TA attributes M= UST use
=C2=A0 =C2=A0 a whitelist of one or more domains that can be updated out of= band.
=C2=A0 =C2=A0 IKE clients with an empty whitelist MUST NOT use any
=C2=A0 =C2=A0 INTERNAL_DNSSEC_TA attributes received over IKE.=C2=A0 Such c= lients MAY
=C2=A0 =C2=A0 interpret receiving an INTERNAL_DNSSEC_TA attribute for a non= -
=C2=A0 =C2=A0 whitelisted domain as an indication that their local configur= ation
=C2=A0 =C2=A0 may need to be updated out of band.

We basically said this is too dangerous to only authenticate via IKE. So now, you need to _also_ do a (remote) configuration update, which
presumbly involves some Enterprise management system or humans.

> The draft *does* says:
> "Other generic or public domains, such as top-level domains, simi= larly SHOULD
> NOT be whitelisted." - this doesn't really answer the above. = 1: It is
> increasingly hard to know what is a "real" TLD (.internal? .= bank? .home?) 2:
> How do I programatically tell if www.foo.net is a "public domain&quo= t;? What is a
> public domain anyway? How is an implementer supposed to address this?<= br>
What we tried to say was that any generic domain open for any registrant for registration should never be accepted. While if you are Red Hat,
maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree
that it is difficult to determine this. The idea of the whitelist is
that VPN clients will show/confirm/enable the listed DNS domains, so
that if Honest Paul's VPN service includes "gmail.com", the enduse= r can
freak out properly.

> It also says:
> "Any updates to this whitelist of domain names MUST happen via ex= plicit human
> interaction to prevent invisible installation of trust anchors." = Is my auntie
> really expected (or competent) to understand what "Your VPN provi= der, TrustVPN
> wants to whitelist com. Do you want to allow this? [Y/N]" means?<= br>
Split-DNS is meant for Enterprise use of actual domains.=C2=A0
=
If your auntie
works for Foo Inc., hopefully she can either have Foo's sysadmin
configure and install her VPN, or if the admin gives her some kind of
profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants = to
whitelist internal.foo.com" and she would be familiar with using the=
in= ternal.foo.com domain from the office.

<= div>
Y= es, I get that the *intended* audience is Enterprises, and that usage doesn= 't really scare me (most enterprise admins already have their fingers s= ufficiently deep inside their employees machines that they can do $whatever= anyway).
My concerns is that this will also be used for the "Buy our = VPN for secure browsing of the torrentz - only $2.99 per month. Punch the m= onkey for a discount!!!!!!!!!!" type people -- I trust my enterprise a= dmins to not DNSSEC / DANE poison me, but I don't necessarily trust (to= pick=C2=A0 at random) CyberGhostVPN -=C2=A0https://offer.cyberghostvpn.com/en_US/trnt/rocket?= aff_id=3D1392&coupon=3DFlashSale2&aff_sub4=3DFlashSale2&=C2= =A0 (I know nothing about this org!)

W

=C2=A0

Note that our text basically meant to say the IKE software should
probably never allow com/net/org/CCtld ever, but that would be difficult to hardcode because we _still_ haven't fixed the PublicSuffix issue :/<= br>
> Also, some of the DNS behavior is handwavey - I think that the documen= t really
> should be reviewed by DNSOP, but will leave it to Eric to make that ca= ll.

What is wavey?

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_D= NSSEC_TA may be
>=C2=A0 =C2=A0passed to another (DNS) program for processing.=C2=A0 As w= ith any network
>=C2=A0 =C2=A0input, the content SHOULD be considered untrusted and hand= led
>=C2=A0 =C2=A0accordingly." feels a bit handwavey. Are there curren= tly any DNSSEC
>=C2=A0 =C2=A0validating clients which can easily take a targeted TA for= a specific domain
>=C2=A0 =C2=A0/ set of domains?
>
> I=E2=80=99m also not quite sure how this interacts with delegations. E= .g:
>
> ex= ample.com=C2=A0 =C2=A0600 IN NS ns01.internal.example
> And then INTERNAL_DNS_DOMAIN(internal.example) =E2=80=94 if the client= runs a local
> recursive, does it need to send the query to ns01 though the VPN or no= t?

It should not think about "through the VPN or not". We had that t= ext
originally, but Tero pointed out a lot of Enterprise VPN's can come up<= br> on demand. So the initial IKE negotiation could be for 10.1.2.3/32, and
include the DNS configuration for the internal auth servers on
192.168.1.1. It needs to configure the DNS so a packet for 192.1.1:53
triggers another IPsec tunnel to be setup.

So to use an unbound example, you only need to drop in the internal DS
record, and the "unbound-control forward example.com ip1 ip2"
configuration pointing to the internal auth servers for example.com.

Paul


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--00000000000021dd39057b2e0365-- From nobody Wed Nov 21 07:17:33 2018 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 4E8451277CC; Wed, 21 Nov 2018 07:17:19 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 kI7V9cRZ6zRd; Wed, 21 Nov 2018 07:17:17 -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 4270B126BED; Wed, 21 Nov 2018 07:17:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430Qxt2y1kzLFt; Wed, 21 Nov 2018 16:10:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542813058; bh=NhQtEHDLbYDs+EVgS3bwmY3V54nSKi8S1V5UoK0gxrY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kTLu/KtdUlXjZT8dt28KZ/OZn40xiJkb60vYFf8rsonQeJV0OfNEKzl3GttXxIxqX QLPEQwcn9opgeOOYn/qON3bn4x7ilsV8pX8MnZ81EiJ2ZwPXVAiE3mJA1Ay4RXR+1u yzhYsRNK++8axrYh1LJfXktJft+XsJFqJtyYeTGM= 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 DhmrYZPrkE1g; Wed, 21 Nov 2018 16:10:50 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 16:10:49 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9397D49ED70; Wed, 21 Nov 2018 10:10:48 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9397D49ED70 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 87D9641C3B26; Wed, 21 Nov 2018 10:10:48 -0500 (EST) Date: Wed, 21 Nov 2018 10:10:48 -0500 (EST) From: Paul Wouters To: Warren Kumari cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, The IESG , draft-ietf-ipsecme-split-dns@ietf.org In-Reply-To: Message-ID: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 15:17:20 -0000 On Wed, 21 Nov 2018, Paul Wouters wrote: >> I’m also not quite sure how this interacts with delegations. E.g: >> >> example.com 600 IN NS ns01.internal.example >> And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a >> local >> recursive, does it need to send the query to ns01 though the VPN or not? I added some text that clarifies dependencies: Deployments that configure INTERNAL_DNS_DOMAIN domains should pay close attention to their use of indirect reference RRtypes in their internal-only domain names. Examples of such RRtypes are CNAME, DNAME, MX or SRV records. For example, if the MX record for "internal.example.com" points to "mx.internal.example.net", then both "internal.example.com" and "internal.example.net" should be sent using an INTERNAL_DNS_DOMAIN Configuration Payload. Paul From nobody Wed Nov 21 07:21:10 2018 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 773481277CC; Wed, 21 Nov 2018 07:20:57 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 rBoCxEC56KLi; Wed, 21 Nov 2018 07:20:56 -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 A872F12426E; Wed, 21 Nov 2018 07:20:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430R9K4b0tzLFt; Wed, 21 Nov 2018 16:20:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542813653; bh=X4IKbZ+XLi+alRf1rxTFUjnGL+TPVTlw5M8m5mi0kuw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EukhwWMxwfKi5gOs7LwTjIGhPJmMkgHKOcYGYs1hM5sDTv8l25Zt6gHTkIm6pfPjc cG8/Dg32p/pvi8+p4hIUhbyHo0A9wyIUTMZF6NU4UO249CPKEB3xLCCt+fxOxSeSIo FYY8R7m2SYrO2uWI3+8jZxdC2dTe65gUXYjiqnWM= 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 m21VXlzHkg3t; Wed, 21 Nov 2018 16:20:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 16:20:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D3B3D49ED70; Wed, 21 Nov 2018 10:20:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D3B3D49ED70 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CABFB41C3B26; Wed, 21 Nov 2018 10:20:45 -0500 (EST) Date: Wed, 21 Nov 2018 10:20:45 -0500 (EST) From: Paul Wouters To: Warren Kumari cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." In-Reply-To: Message-ID: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 15:20:58 -0000 On Wed, 21 Nov 2018, Warren Kumari wrote: > Yes, I get that the *intended* audience is Enterprises, and that usage doesn't really scare me (most > enterprise admins already have their fingers sufficiently deep inside their employees machines that they can > do $whatever anyway). > My concerns is that this will also be used for the "Buy our VPN for secure browsing of the torrentz - only > $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type people -- I trust my enterprise admins to > not DNSSEC / DANE poison me, but I don't necessarily trust (to pick  at random) CyberGhostVPN > - https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2&  (I > know nothing about this org!) These VPN services need to take ALL your network traffic. We now more explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be ignored when the VPN configuration is not a split tunnel one. This can still be abused by VPN service providers but it would require some serious hacking since most remote access profiles will only offer to set a source/dest IP tunnel for YourTempAssignedIP/32 <-> 0.0.0/0 That is, if you connect to vpn.nohats.ca, it will give you 193.111.157.66 as INTERNAL_IP4_ADDRESS and the IPsec policy will cover 193.111.157.66/32 <-> 0.0.0.0/0 only. In which case our new attributes are ignored. They could do something like: 193.111.157.66/32 <-> 0.0.0.0/128 to get their attribute accepted, but the VPN would not work for half the internet. Of course, if their only goal is to screw you over and get your gmail.com traffic on 172.217.1.165, then giving you 172.217.0.0/16 would work and all your other traffic would simply go out in the clear. And if you accept their provisioning profile, they could also override TLSA records. We tried to close all of this as much as possible so that you can still use enterprise split tunnel with DNS while making it as hard as possible for VPN services to not abuse this. But in the end, it all depends on how badly you want your VPN service to see cute kittens. Paul From nobody Wed Nov 21 08:00:52 2018 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 221061277CC; Wed, 21 Nov 2018 08:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 Irqcq8A9xMmL; Wed, 21 Nov 2018 08:00:44 -0800 (PST) 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 3BD79130DBE; Wed, 21 Nov 2018 08:00:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A19CA20089; Wed, 21 Nov 2018 11:00:38 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 155FDB98; Wed, 21 Nov 2018 11:00:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1306FB93; Wed, 21 Nov 2018 11:00:43 -0500 (EST) From: Michael Richardson To: Warren Kumari cc: "The IESG" , ipsec@ietf.org In-Reply-To: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:00:51 -0000 --=-=-= Content-Type: text/plain Warren, I see your concern, but I don't think it's much of an in practice. Warren Kumari wrote: > Lots of "regular" users use VPNs for access the Internet, either to bypass > censorship / content restrictions, or to improve their privacy. These are not Sadly, very few regular users use IPsec/IKEv2 for this kind of access. So, really, this comment applies to a vanishing few number of people. (There are a few: Openswan is run by at least one big one to provide IPsec/IKEv2 access, but I note that they provide 5 other protocols as well). In almost all cases the VPN provider is in control of the software that is installed on the client system, so they can hijack paypal already. Few support IPv6 or DNSSEC for the VPN either. Some are effectively HTTPS proxies only, so ALG gateways, with HTTPS certificate evaluation done by the VPN provider. This is not much of a new threat. In the remote cases where a user uses IPsec/IKEv2, and configures it themselves (perhaps from instructions), then they could easily omit the: trust-ikev2-internal-dns=true configuration option. In the case where they don't configure it themselves, then DNSSEC would get hijacked at configuration time, does not matter what the protocol does. **** Where I think there may be issues is when one has a non-technical consultant who has an Enterprise-VPN to *two* customers, that the two Enterprises could arrange to do things to each other via the cross-site scripting via the consultant. I think the document does a good job of making it clear that there are issues the client implementer needs to worry about. **** But, this seems terribly unlikely since just getting two VPNs installed (and compatible) and running at the same time is such deep VPN-fu, that it's like only half the IPsec WG members that could ever make this work anyway. > "Any updates to this whitelist of domain names MUST happen via explicit human > interaction to prevent invisible installation of trust anchors." Is my auntie > really expected (or competent) to understand what "Your VPN provider, TrustVPN > wants to whitelist com. Do you want to allow this? [Y/N]" means? If she managed to install the TrustVPN herself, then I think yes. Otherwise, she is going to call whomever installed the thing (I guess you), and ask them. {I think walled-garden DNS (whether for Enterprise use or IPTV) is security threatre myself. IPv6 is here, use it, and stop building coconut networks.} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv1gSoACgkQgItw+93Q 3WWNYwf/QLuQDYQwW0uV8Gx89Ap0DUXqHXIu2clx5cbb5p5Qeh7SLoydvsjNXiu3 4GKXBlrdcbRVcYchRL1IPTTrEe6UITnIJXYMQGaes/qz0w0qatE8rDLn0rGRcCeI sLnIdtJoMpkKl7DgFveWMceXdBeV6s9iqRVy67nkphyonkYg721TbSNfdSGDouq2 n/9vG2ROCGHiqsGVX8OlB+8kZ9vT1ok4TDCRm815EOiWXv1nmV5+CSd+R74N02Mm fAysgE1xsdwTf6d7+TkAWaeocQA3hV08kdARvSmkG9Edl7UhMsyFNIBjgyHLpBpK EGhiaSg8X/3Zr3J3d+ljcbc6AHgQWg== =qPZn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 21 08:05:21 2018 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 AF5C8130DEE for ; Wed, 21 Nov 2018 08:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 eRz1mhOH7pDV for ; Wed, 21 Nov 2018 08:05:17 -0800 (PST) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 325D21277CC for ; Wed, 21 Nov 2018 08:05:14 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id z5so1963371wrt.11 for ; Wed, 21 Nov 2018 08:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0GyFhOuGjS7KFSZ2wNV9YOrTNxHFl01TWZ8f57XROGg=; b=qi4a/NswDb+qy1S/4GCAgu9JB/zX12HGZHAkjaaD0hlenxdf+TMGv6SFyYqeiF+ZLH j/34OANtTxYxVrtY2jPJP250B8iLPvi2vPRYPf2rVw+D6J/JHEbcwD6RlvidOiIX6rzR rglOXvDahwCfeqysennXtxmTkGvSgrgjd5VmUPLgUaWNiKVYE/af9pURxpWXBcLykrj9 Q5jyCshn4VkLIzCVCilkc50Fpa7Hc3WpaorWMXEjQz2+tbeRa16pGxR/F7SoLra5Nt+5 jWDpRVT5lZRUS5P8saZV1+4SUr3gh1kN4qjxcSsnJQWIz5zE29suCHRWdtsuYd6IOOt2 bKJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0GyFhOuGjS7KFSZ2wNV9YOrTNxHFl01TWZ8f57XROGg=; b=AUhgZk+zOH1nSxqlWHJc8jZz/rTA/fCgqh7sRgQpr1wwWH0LtCa1dH5Yt3q+r5t9Ju nxxHnLnefl/+m8TKOMRpQpyIHGexJTLAEPaMJcIQtC5OQpo3ybH1vVS6pX2Cq+g83+uy in+EeLW2KGzVhGOYoYvsI/OvBuSUT+0ZGmIxHuOjAGKQ4kSCznWn+SBeb9h6cleT25bK djSH34TUrt+gtHUMsxjBmoNN97422iFBFDOiSlOcOnDf9KFTrtTMRJ6/h9dHYZc7cqzR belMqS8Cd4ryVlYBWeCDaCrMe9u0vWz4Gx4yki3AP3DJWkOcHBmA4j/2mEnIbrZiuVwM WgeA== X-Gm-Message-State: AA+aEWboeJ54GgiJnUlJ0k2NQsGFlSeVdHNvMAv6AgaNdxhZOKd2hjWE mANxPZ9tmFy5FS8f4XNIqxt2j/94WBy82ANLSuF3zA== X-Google-Smtp-Source: AFSGD/XlzmO/XePEYV06omF03o/lEkwdZFk6/wG1tQZqBvM4nUeU1i9788LpBi1eZTm1wqkjukmOm2C8dpLVxXYd7C4= X-Received: by 2002:a5d:4e82:: with SMTP id e2mr6208863wru.291.1542816312051; Wed, 21 Nov 2018 08:05:12 -0800 (PST) MIME-Version: 1.0 References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Wed, 21 Nov 2018 11:04:34 -0500 Message-ID: To: Paul Wouters Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Type: multipart/alternative; boundary="0000000000003bde3d057b2eea3e" Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:05:19 -0000 --0000000000003bde3d057b2eea3e Content-Type: text/plain; charset="UTF-8" On Wed, Nov 21, 2018 at 10:20 AM Paul Wouters wrote: > On Wed, 21 Nov 2018, Warren Kumari wrote: > > > Yes, I get that the *intended* audience is Enterprises, and that usage > doesn't really scare me (most > > enterprise admins already have their fingers sufficiently deep inside > their employees machines that they can > > do $whatever anyway). > > My concerns is that this will also be used for the "Buy our VPN for > secure browsing of the torrentz - only > > $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type people > -- I trust my enterprise admins to > > not DNSSEC / DANE poison me, but I don't necessarily trust (to pick at > random) CyberGhostVPN > > - > https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2& > (I > > know nothing about this org!) > > These VPN services need to take ALL your network traffic. We now more > explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be > ignored when the VPN configuration is not a split tunnel one. > > This can still be abused by VPN service providers but it would require > some serious hacking since most remote access profiles will only offer > to set a source/dest IP tunnel for YourTempAssignedIP/32 <-> 0.0.0/0 > > That is, if you connect to vpn.nohats.ca, it will give you > 193.111.157.66 as INTERNAL_IP4_ADDRESS and the IPsec policy will > cover 193.111.157.66/32 <-> 0.0.0.0/0 only. In which case our new > attributes are ignored. They could do something like: > > 193.111.157.66/32 <-> 0.0.0.0/128 to get their attribute accepted, but > the VPN would not work for half the internet. So, what my (OpenVPN) client seems to do is send: 193.111.157.66 <-> 0.0.0.0/1 193.111.157.66 <-> 128.0.0.0/1 This "overrides" my default of 0.0.0.0/0, and (depending on how you read things) could be considered a split tunnel, but with both sides routed through the tunnel. You could also do silly things like: 193.111.157.66 <-> 0.0.0.0/1 193.111.157.66 <-> 128.0.0.0/2 193.111.157.66 <-> 192.0.0.0/3 193.111.157.66 <-> 224.0.0.0/4 (I think that this covers basically all space except 240.0.0.0, but I haven't had any coffee yet). > Of course, if their only > goal is to screw you over and get your gmail.com traffic on 172.217.1.165, > then giving you 172.217.0.0/16 would work and all your other traffic > would simply go out in the clear. And if you accept their provisioning > profile, they could also override TLSA records. > > We tried to close all of this as much as possible so that you can still > use enterprise split tunnel with DNS while making it as hard as possible > for VPN services to not abuse this. Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to do this through "normal" enterprise tools methods this would work. (It started writing that the zone could also be unsigned, but that obviously doesn't work in the case of non-delegated "TLDs"...) W > But in the end, it all depends on > how badly you want your VPN service to see cute kittens. > > Paul > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000003bde3d057b2eea3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 21, 2018 at 10:20 AM Paul Wouters = <paul@nohats.ca> wrote:
On Wed, 21 Nov 2018, Wa= rren Kumari wrote:

> Yes, I get that the *intended* audience is Enterprises, and that usage= doesn't really scare me (most
> enterprise admins already have their fingers sufficiently deep inside = their employees machines that they can
> do $whatever anyway).
> My concerns is that this will also be used for the "Buy our VPN f= or secure browsing of the torrentz - only
> $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type = people -- I trust my enterprise admins to
> not DNSSEC / DANE poison me, but I don't necessarily trust (to pic= k=C2=A0 at random) CyberGhostVPN
> -=C2=A0https://offer.cyberghostvpn.com/en_US/trnt/ro= cket?aff_id=3D1392&coupon=3DFlashSale2&aff_sub4=3DFlashSale2&=C2=A0 (I
> know nothing about this org!)

These VPN services need to take ALL your network traffic. We now more
explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be
ignored when the VPN configuration is not a split tunnel one.

This can still be abused by VPN service providers but it would require
some serious hacking since most remote access profiles will only offer
to set a source/dest IP tunnel for YourTempAssignedIP/32 <-> 0.0.0/0<= br>
That is, if you connect to vpn.nohats.ca, it will give you
193.111.157.66 as INTERNAL_IP4_ADDRESS and the IPsec policy will
cover 193.111.157.66/32 <-> 0.0.0.0/0 only. In which case our new
attributes are ignored. They could do something like:

1= 93.111.157.66/32 <-> 0.0.0.0/128 to get their attribute accepted, bu= t
the VPN would not work for half the internet.

So= , what my (OpenVPN) client seems to do is send:
193.111.157.66 <-> 0.0.0.0/1
= 193.111.157.66 <-> 128.0.0.0/1

This "overrides" my defa= ult of 0.0.0.0/0, and (depending on how yo= u read things) could be considered a split tunnel, but with both sides rout= ed through the tunnel.
You could also do = silly things like:
193.111.157.66 <-> 0.0.0.0/1
193.111.157.66 <-> 128.0.0.0/2
= 193.111.157.66 <-> 192.0.0.0/3
193.111.157.66 <-> 224.0.0.0/4=C2=A0=C2=A0
(I think that t= his covers basically all space except 240.0.0.0, but I haven't had any = coffee yet).
=C2=A0
Of course, if their only
goal is to screw you over and get your gmail.com traffic on 172.217.1.165,
then giving you 172.217.0.0/16 would work and all your other traffic
would simply go out in the clear. And if you accept their provisioning
profile, they could also override TLSA records.

We tried to close all of this as much as possible so that you can still
use enterprise split tunnel with DNS while making it as hard as possible for VPN services to not abuse this.

Well, if you= removed the DNSSEC_TA bit, and expected enterprise tools to do this throug= h "normal" enterprise tools methods this would work.
(It started = writing that the zone could also be unsigned, but that obviously doesn'= t work in the case of non-delegated "TLDs"...)

W

=C2=A0
But= in the end, it all depends on
how badly you want your VPN service to see cute kittens.

Paul


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000003bde3d057b2eea3e-- From nobody Wed Nov 21 08:32:41 2018 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 09E761274D0; Wed, 21 Nov 2018 08:32:40 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 VyjscveQs3CL; Wed, 21 Nov 2018 08:32:38 -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 EC360130F86; Wed, 21 Nov 2018 08:32:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430Slv3wy9zLMX; Wed, 21 Nov 2018 17:32:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542817947; bh=HEs+UBdFMYBjrngkMe0t9F9w1hIZB/aRUeeLQBG9E5M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=P2nmcSCDCeBbC8H9Cp8hheFqgCoztP1KpEJwnwEPfewWeRs6fj6O8mB+n4BIxlwEN 94d/czhTYHDQW8LtRTpPO/8taqUjNXLhAU0imh6Kyrdc9cLLbArEjgcjSaTo3GZFAn kv32d2eMSsvBvUcQuQo+w6ed8wTc5KQ53w6eP7ng= 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 PB39nPNJYFrv; Wed, 21 Nov 2018 17:32:25 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 17:32:24 +0100 (CET) Received: from [192.168.1.10] (node-11u3.pool-118-173.dynamic.totbb.net [118.173.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 9562549ED70; Wed, 21 Nov 2018 11:32:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9562549ED70 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: <25704.1542816043@localhost> Date: Wed, 21 Nov 2018 23:32:19 +0700 Cc: Warren Kumari , ipsec@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> To: Michael Richardson Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:32:40 -0000 On Nov 21, 2018, at 23:00, Michael Richardson wrote:= > Sadly, very few regular users use IPsec/IKEv2 for this kind of access. This is very incorrect. Almost all VPN providers for apple (OSX and iOS) use IKEv2 with CP. Based on= numbers of concurrent users I have seen from some vendors using libreswan, w= e are talking in the orders of 100=E2=80=99s of thousands of users. And more and more Windows L2TP/IPsec and XAUTH deployments are moving to IKE= v2.=20 One of the main reasons: MOBIKE with phones using wifi and 4/5G and network s= witching. For Android, the situation is bad. Due to the OS not properly supporting IKE= v2, most VPN services bundle openvpn apps for android and very few bundle st= rongswan with its userland ESP that can do IKEv2. > In almost all cases the VPN provider is in control of the software that is= > installed on the client system, so they can hijack paypal already. This is also incorrect. All OSX and iOS provisioning happens via .mobileconf= ig profiles or apps using apple API=E2=80=99s that are equivalent. None of t= heir apps can do weird things like hijacking paypal.com domain other then mo= difying the DNS stream after IPsec decryption. Any installed root CA as part= of the VPN provisioning is limited to that VPN profile only and does not af= fect HTTPS. > Few support IPv6 or DNSSEC for the VPN either. That is correct but with SNAFUs like NAT64 breaking IPsec the telcos have he= lped greatly in that situation being addressed for IPv6. >=20 > I think the document does a good job of making it clear that there > are issues the client implementer needs to worry about. > **** I have improved the text but I am waiting for my co-author to proofread and a= gree to my changes. It hopefully addresses Warrens concerns as best we can. > But, this seems terribly unlikely since just getting two VPNs installed > (and compatible) and running at the same time is such deep VPN-fu, that it= 's > like only half the IPsec WG members that could ever make this work anyway.= It is currently uncommon indeed but I think and hope we will see more of thi= s, especially when we all want a continuous VPN link up to our home network.= Paul From nobody Wed Nov 21 08:36:29 2018 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 AB756130F7F for ; Wed, 21 Nov 2018 08:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 MfEyrcnKYa4z for ; Wed, 21 Nov 2018 08:36:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95E6130FD7 for ; Wed, 21 Nov 2018 08:36:19 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAAF720089; Wed, 21 Nov 2018 11:36:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 416ACBBD; Wed, 21 Nov 2018 11:36:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3EB3EBB7; Wed, 21 Nov 2018 11:36:18 -0500 (EST) From: Michael Richardson To: Warren Kumari , ipsec@ietf.org In-Reply-To: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:36:27 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > These VPN services need to take ALL your network traffic. We now more > explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be > ignored when the VPN configuration is not a split tunnel one. And, there is no reason for this kind of VPN service to have any INTERNAL_DNS_DOMAIN, so it would be reasonable for a well configured client to simply ignore such things. (It's not like they have .internal or .corp for you... Some of the services offer virtual corporation services, but that's really a different kettle of fish) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv1iYEACgkQgItw+93Q 3WVs8Qf/SivsZ/Y/wa/B3F8soYI6vVEzucbMzohq09zZypy4yl8zLNrdjpNXF3Ys BOgdNAtw97lXnZrAMtJ9Qm+FV0ZrzxKFhWU45yk7nROj+kzhuS1rUZ2dqFSYrcp/ L8kTe1bTXNZbzdoVvadS8IxtBFUFaB0uyaZU4HLwkdDUn2ZOnXHMpieA0p1h0nso pHuFxtL2+0/0HWqwOPv57sshVXh6uuCzqob+64eyonuW5UheRVjucL6yZABTBL8G SHo8suEamQ0Awt+lXbPHLaOv8k/THQGwsrSh7nze5NObAVk5tibecZjf1x7zsBKn 7J8F5fkB5hgFI4zj0fG2F1CTUvfrmQ== =JU3l -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 21 08:40:56 2018 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 D3467128AFB; Wed, 21 Nov 2018 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 SyAXe-v15oSQ; Wed, 21 Nov 2018 08:40:44 -0800 (PST) Received: from gw-v.mimosa.com (gw-v.mimosa.com [98.158.128.23]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC43A130DFA; Wed, 21 Nov 2018 08:40:43 -0800 (PST) Received: from redeye.mimosa.com (redeye.mimosa.com [192.139.70.93]) by gw-v.mimosa.com (Postfix) with ESMTPS id DD2B4160153; Wed, 21 Nov 2018 11:40:42 -0500 (EST) Date: Wed, 21 Nov 2018 11:40:42 -0500 (EST) From: "D. Hugh Redelmeier" Reply-To: "D. Hugh Redelmeier" To: ipsec@ietf.org, The IESG In-Reply-To: <25704.1542816043@localhost> Message-ID: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:40:46 -0000 | From: Michael Richardson | In almost all cases the VPN provider is in control of the software that is | installed on the client system, so they can hijack paypal already. VPN providers should not provide software to their clients. That's a bug and should not be encouraged by the committee. The point of a standard is that any IPSec implementation should be able to connect with any other IPsec implementation. The default provider of VPN software ought to be the provider of the OS for the client's machine. The client should be able to choose any conformant implementation. I admit that we have failed to make interop easy and normal, but that's where we should be heading. From nobody Wed Nov 21 08:42:12 2018 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 81220128AFB; Wed, 21 Nov 2018 08:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 pqlcdW_BaGJ7; Wed, 21 Nov 2018 08:42:09 -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 B58BD1274D0; Wed, 21 Nov 2018 08:42:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430Sz32qPkzLFN; Wed, 21 Nov 2018 17:42:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542818527; bh=48g0hU2ObrH61V8uyDmgzEm9nI1X39smCgS+TqpbSk0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Y/UIZaybw7h5UwoQzCLZ8xHB51YfxHXQCiw4s3n+qyi6GJ4rsOqdOapkaiklcEDh2 btvJik2kgct80R58YBYajV48XinSc+Hy3AWDYrVmXNeJ3DogKCN9HUvKhZCK4Hl+yO wDqnVTh39PHikqOaLabo2l6sNec2d/nWjxp6hI+A= 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 pujYeHcUHddL; Wed, 21 Nov 2018 17:42:04 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 17:42:03 +0100 (CET) Received: from [192.168.1.10] (node-11u3.pool-118-173.dynamic.totbb.net [118.173.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 5BBA449ED70; Wed, 21 Nov 2018 11:42:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5BBA449ED70 Content-Type: multipart/alternative; boundary=Apple-Mail-64362AB2-0BF5-4399-A64B-B3A7054980AF Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: Date: Wed, 21 Nov 2018 23:41:55 +0700 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Transfer-Encoding: 7bit Message-Id: <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> To: Warren Kumari Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:42:10 -0000 --Apple-Mail-64362AB2-0BF5-4399-A64B-B3A7054980AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 21, 2018, at 23:04, Warren Kumari wrote: >=20 >>=20 >=20 > Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to d= o this through "normal" enterprise tools methods this would work. That is basically what we did with the mandatory white list, except now the i= nternal zones can still do rollovers without locking out all VPN clients tha= t haven=E2=80=99t recently done some (automatic or manual) provisioning upda= te that isn=E2=80=99t standardized. And in the end, if a user treats/trusts a generic VPN service provider the s= ame as an enterprise provisioning system, then we cannot define them to be d= ifferent. That is, whatever you define as out of band, non-ike enterprise pr= ovisioning with be equally weak to this attack if provided by the generic VP= N provider. Kittens all the way down. Paul > (It started writing that the zone could also be unsigned, but that obvious= ly doesn't work in the case of non-delegated "TLDs"...) >=20 > W >=20 > =20 >> But in the end, it all depends on >> how badly you want your VPN service to see cute kittens. >>=20 >> Paul >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad idea i= n the first place. > This is like putting rabid weasels in your pants, and later expressing reg= ret at having chosen those particular rabid weasels and that pair of pants. > ---maf --Apple-Mail-64362AB2-0BF5-4399-A64B-B3A7054980AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 21, 2018, at 23:04, Warren Kumari &l= t;warren@kumari.net> wrote:
<= div dir=3D"ltr">

Well, if you removed the DNSSEC_TA bit, and expected ent= erprise tools to do this through "normal" enterprise tools methods this woul= d work.

That is basically what we did with the mandatory white list, except no= w the internal zones can still do rollovers without locking out all VPN clie= nts that haven=E2=80=99t recently done some (automatic or manual) provisioni= ng update that isn=E2=80=99t standardized.

And in t= he end, if a user treats/trusts a generic VPN service provider the same as a= n enterprise provisioning system, then we cannot define them to be different= . That is, whatever you define as out of band, non-ike enterprise provisioni= ng with be equally weak to this attack if provided by the generic VPN provid= er. Kittens all the way down.

Paul



(It starte= d writing that the zone could also be unsigned, but that obviously doesn't w= ork in the case of non-delegated "TLDs"...)

W

 <= /div>
But in the end, it al= l depends on
how badly you want your VPN service to see cute kittens.

Paul


--
I don't think the execution is relevant when it was= obviously a bad idea in the first place.
This is like putting rabid weas= els in your pants, and later expressing regret at having chosen those partic= ular rabid weasels and that pair of pants.
   ---maf
= --Apple-Mail-64362AB2-0BF5-4399-A64B-B3A7054980AF-- From nobody Wed Nov 21 08:53:33 2018 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 A3533128AFB for ; Wed, 21 Nov 2018 08:53:31 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 q7fJDUq_jC3C for ; Wed, 21 Nov 2018 08:53:30 -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 61FD5123FFD for ; Wed, 21 Nov 2018 08:53:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430TD80N7KzLDW; Wed, 21 Nov 2018 17:53:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542819208; bh=g01GHFTAB4LqEEPOCz/PGiwBkq/di/i3UQTENRBA1Ls=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=P3MBG4Pl/r6cZv57UdVmufM2Xd78M2pTUf++294EKe1nlOFRNOXmEkvVws5XPYsjZ hJvMH048eTJS1KZptai28dHnlEBRECBU922Mhb0buZ6RQfyNjpnlniM1oGGOKdlHXP LZX70ZIvbpbZ7SmpnwBneXoWGncHK2qMw5tYbNSg= 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 pCse9QxKzVJL; Wed, 21 Nov 2018 17:53:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 17:53:25 +0100 (CET) Received: from [192.168.1.10] (node-11u3.pool-118-173.dynamic.totbb.net [118.173.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 5D1AC49ED70; Wed, 21 Nov 2018 11:53:24 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5D1AC49ED70 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: Date: Wed, 21 Nov 2018 23:53:20 +0700 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4AC115F8-50E1-48D7-84FA-0177F7B06A45@nohats.ca> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> To: "D. Hugh Redelmeier" Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 16:53:32 -0000 > On Nov 21, 2018, at 23:40, D. Hugh Redelmeier wrote: >=20 > VPN providers should not provide software to their clients. That's a > bug and should not be encouraged by the committee. And you can see the security nightmare it causes in the Android Play Store w= ith zillions of (un?)modified openvpn code that no one knows what it exactly= does. Where as with Apple, the VPN apps provide a custom UI to the user but it is a= ll using the systems IKE/IPsec stack and the standard VPN was information to= ols of the OS can be used to see what the VPN configuration is (currently no= t for the DNS settings but a bug report has been verbally submitted for this= a while ago :)=20 > The point of a standard is that any IPSec implementation should be > able to connect with any other IPsec implementation. The default > provider of VPN software ought to be the provider of the OS for the > client's machine. +1 > The client should be able to choose any conformant=20 > implementation. For opensource based solutions, sure. For proprietary devices I would hope t= hey just ship with only one implementation. > I admit that we have failed to make interop easy > and normal, but that's where we should be heading. It is getting much better compared to what we had for IKEv1 (with PFS and re= key issues being the main thing I see going wrong) Paul From nobody Wed Nov 21 09:04:26 2018 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 1873F123FFD for ; Wed, 21 Nov 2018 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 Y-KhlUrRU_i5 for ; Wed, 21 Nov 2018 09:04:23 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 E47D9130DF1 for ; Wed, 21 Nov 2018 09:04:22 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id c126so6485032wmh.0 for ; Wed, 21 Nov 2018 09:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kInffnsq33msklFEyMufTafTxg/iD/og/Cwmsx4LeSw=; b=ctiXW8VMx/5N0LHzuqlqjD2eK7OVAgdiY7uVljqKM6nSFQ6SA1MPkqRYBqCU1vG/Q7 Hlif7EkAAxHlS73cMNfqY+tI5g9YUcft/UumQ+9XIO5bcoa2bnITE/JeI9E0v2lJM1Q0 cEpFACbcAZ4dSfaAZffFS6NI1u0PXFAffRcOs9/IrAB5+om9QmNt4lI6LnL8AKjVlclh Z2/oUeiAXur3Vgfavyy+0SIl2X9KcS8MAidPY/Feeku5Y5bb54g3JiU7uOSDWFM3qd+3 R656lMFB6updArzDAeREB2ZuwOQyfOt/f3PAo5PiA1rkB9Ns0jc/x5VSvNpMd0kUzNgN GWcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kInffnsq33msklFEyMufTafTxg/iD/og/Cwmsx4LeSw=; b=GfmdwL6UISep71uCtdvS3A80zRp2xX1pRKdKyeH9Ysx01K0qWmhcwKumpfhgYMDwcE MPhnWM9cKh6dUV2H0ST7BfEFi9dvFt+wNo7re3sV1sOuz9Jr1DyVo8wM+upoHier7SWX fbGpyXz6vhtq0F1YDbk2jJPXMyYh1bf9+s0gqMYmX9xdN9k3MOMHQGrH4bfwIFlMui92 Yklc+YiwqqH7y5xL4U5GV3kbT7v/T0K8SRvRL1Em0us+3ZL4CPqs4eq0rFhVzTH4bSci tYLSSPscjknzzuB+BTHz0IQBdHEJUrwsT+DGPxh3FQmbupJCHJalC20nMnCOzMlU5QMR dHwQ== X-Gm-Message-State: AA+aEWZD+kNxvvrioGPATtdvZuSUM4Qk3dTYi+hhCGmSDgi7G3TZoTgb TAHlNe6zYc1ZhCqtCDlXPuv9w7y8qUcGTd9k68aoHQ== X-Google-Smtp-Source: AFSGD/XtbwqO+SB00YrRhVAsMiB5IvHIe87uZXsTCUpSAKRT3JFdn5doOompfFTiaaO9klOsE9tG3+kWKr94q1GIE3w= X-Received: by 2002:a1c:184:: with SMTP id 126mr2842745wmb.24.1542819860890; Wed, 21 Nov 2018 09:04:20 -0800 (PST) MIME-Version: 1.0 References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> In-Reply-To: <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> From: Warren Kumari Date: Wed, 21 Nov 2018 12:03:44 -0500 Message-ID: To: Paul Wouters Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Type: multipart/alternative; boundary="000000000000c2e170057b2fbdf8" Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 17:04:25 -0000 --000000000000c2e170057b2fbdf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, I'm still fairly uncomfortable - having a VPN provider able to override my DNSSEC configuration worries me, especially if things like TLSA / DNSSEC Chain Extension / similar are used. I was starting to come to terms with this, as I'd assumed that the common deployment scenario was "Install (as root / admin) this binary package containing a VPN client.", in which case a malicious VPN provider already has the ability to do, well, basically anything (and doesn't need this method to be malicious), but if this isn't the universal case, I'm concerned again... A number of other IESG folk were also concerned - as a compromise, I'm going to ask DNSOP to have a look at the document (it is, after all, quite DNS related) and get their feedback. I am sympathetic to the general use case, but really don't want this to open scary security holes / decrease "trust" in DNSSEC. W On Wed, Nov 21, 2018 at 11:42 AM Paul Wouters wrote: > On Nov 21, 2018, at 23:04, Warren Kumari wrote: > > > Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to > do this through "normal" enterprise tools methods this would work. > > > That is basically what we did with the mandatory white list, except now > the internal zones can still do rollovers without locking out all VPN > clients that haven=E2=80=99t recently done some (automatic or manual) pro= visioning > update that isn=E2=80=99t standardized. > > And in the end, if a user treats/trusts a generic VPN service provider th= e > same as an enterprise provisioning system, then we cannot define them to = be > different. That is, whatever you define as out of band, non-ike enterpris= e > provisioning with be equally weak to this attack if provided by the gener= ic > VPN provider. Kittens all the way down. > > Paul > > > > (It started writing that the zone could also be unsigned, but that > obviously doesn't work in the case of non-delegated "TLDs"...) > > W > > > >> But in the end, it all depends on >> how badly you want your VPN service to see cute kittens. >> >> Paul >> > > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000c2e170057b2fbdf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, I'm still fairly uncomfortable - having a VPN provider = able to override my DNSSEC configuration worries me, especially if things l= ike TLSA / DNSSEC Chain Extension / similar are used.
I was starting to com= e to terms with this, as I'd assumed that the common deployment scenari= o was "Install (as root / admin) this binary package containing a VPN = client.", in which case a malicious VPN provider already has the abili= ty to do, well, basically anything (and doesn't need this method to be = malicious), but if this isn't the universal case, I'm concerned aga= in...

A number of other IESG folk were also concerned - as a compromis= e, I'm going to ask DNSOP to have a look at the document (it is, after = all, quite DNS related) and get their feedback.=C2=A0
I am sympathetic to t= he general use case, but really don't want this to open scary security = holes / decrease "trust" in DNSSEC.

W


On Wed, Nov 21, 2018 at 11:42 AM Paul W= outers <paul@nohats.ca> wrote:<= br>
On Nov 21, 2018, = at 23:04, Warren Kumari <warren@kumari.net> wrote:


<= div style=3D"font-family:verdana,sans-serif">Well, if you removed the DNSSE= C_TA bit, and expected enterprise tools to do this through "normal&quo= t; enterprise tools methods this would work.
<= /div>

That is basically what we did w= ith the mandatory white list, except now the internal zones can still do ro= llovers without locking out all VPN clients that haven=E2=80=99t recently d= one some (automatic or manual) provisioning update that isn=E2=80=99t stand= ardized.

And in the end, if a user treats/trusts a= generic VPN service provider the same as an enterprise provisioning system= , then we cannot define them to be different. That is, whatever you define = as out of band, non-ike enterprise provisioning with be equally weak to thi= s attack if provided by the generic VPN provider. Kittens all the way down.=

Paul



(It started writing that the zone could also be unsigned, = but that obviously doesn't work in the case of non-delegated "TLDs= "...)

W

=C2=A0
But in the end, it all= depends on
how badly you want your VPN service to see cute kittens.

Paul


--
I don't think the execu= tion is relevant when it was obviously a bad idea in the first place.
Th= is is like putting rabid weasels in your pants, and later expressing regret= at having chosen those particular rabid weasels and that pair of pants.=C2=A0 =C2=A0---maf


--
I don't think the execution is relevant when it was obvious= ly a bad idea in the first place.
This is like putting rabid weasels in = your pants, and later expressing regret at having chosen those particular r= abid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--000000000000c2e170057b2fbdf8-- From nobody Wed Nov 21 09:56:04 2018 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 BF246128CE4; Wed, 21 Nov 2018 09:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 BPPqLiUZdEcS; Wed, 21 Nov 2018 09: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 1C7E3128AFB; Wed, 21 Nov 2018 09:55:50 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430Vc16ncNzLMc; Wed, 21 Nov 2018 18:55:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542822945; bh=xJcW6gIW1XALG2tAJ6WemV2XU95mxCm7savLKHvwFNg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WQOjPJ6PZB58n4K9e9FGc1bMa6+GSnQ5Kfq4xlXRFm51YMwK2nQ6g8CFovzHahKHN gLtl2nml1X1V1usOVrXY/dBu6sCdA4CHICHry9Z5Ss0SftqArl8CWpnUJpWguHD474 qbqD5jF692HtJ3TD1GifJEXRH87VnDu25in1DlAs= 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 4SrseJHKWkjF; Wed, 21 Nov 2018 18:55:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 18:55:40 +0100 (CET) Received: from [192.168.1.10] (node-11u3.pool-118-173.dynamic.totbb.net [118.173.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id EE4C849ED70; Wed, 21 Nov 2018 12:55:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EE4C849ED70 Content-Type: multipart/alternative; boundary=Apple-Mail-1882E732-36B5-41D2-AF1F-37484AB459CE Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: Date: Thu, 22 Nov 2018 00:55:34 +0700 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Transfer-Encoding: 7bit Message-Id: <2010C828-FE1A-4500-88A7-F3A809440464@nohats.ca> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> To: Warren Kumari Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 17:55:53 -0000 --Apple-Mail-1882E732-36B5-41D2-AF1F-37484AB459CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Nov 22, 2018, at 00:03, Warren Kumari wrote: >=20 >=20 >=20 > I am sympathetic to the general use case, but really don't want this to op= en scary security holes / decrease "trust" in DNSSEC. By not allowing VPNs to use an enterprise internal dnssec trust anchor, you a= lso erode trust in dnssec, or end up not using dnssec internally at all when= connected via VPN. I suggest you wait for me to push -15 before asking dnsop. It should be out t= oday or tomorrow and contains quite some changes related to this topic. Paul --Apple-Mail-1882E732-36B5-41D2-AF1F-37484AB459CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 22, 2018, at 00:03, Warren Kumari &l= t;warren@kumari.net> wrote:
<= div dir=3D"ltr">


I am sympathetic to the general use case, but really don't want t= his to open scary security holes / decrease "trust" in DNSSEC.

By not allowing VPNs to use an enterprise in= ternal dnssec trust anchor, you also erode trust in dnssec, or end up not us= ing dnssec internally at all when connected via VPN.

I su= ggest you wait for me to push -15 before asking dnsop. It should be out toda= y or tomorrow and contains quite some changes related to this topic.

Paul

= --Apple-Mail-1882E732-36B5-41D2-AF1F-37484AB459CE-- From nobody Wed Nov 21 09:58:51 2018 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 F2EBC130F29 for ; Wed, 21 Nov 2018 09:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 W_wiXEvydnrD for ; Wed, 21 Nov 2018 09:58:38 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 36AE5130E69 for ; Wed, 21 Nov 2018 09:58:38 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id c126so6653254wmh.0 for ; Wed, 21 Nov 2018 09:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S+vHzL+axkFXm6xp69G0kh3cYsvbHG2zAkh/ccjqW3o=; b=cn1r10v70jUPhmZzA1c1C4TOBvTd6svvf5gViObLV9yOYWCh9PEUWVob2nlHfa1ZUj MJPy3FH1CxvUqE/KMAjaKJEXysObCehW9nPAResGpH7bszC6/c+T4QI32NNuV0+EH433 ciQbJa5rCAw2OwRbmgo9hmabS5boc7titDbuWlFxzw1YQqHsQO2UFhnAUfj6DLn/O7VY uKiBZu2+BLhbeBJC8QT6+pu4oI4Q0b75pgN8Odt797DMXWQSNjk8vmTPaAK6rdUFVwfV 7rum9EWoQMaZecGvOR7yertffv+Y+cKyzEC30bA36Q78BEHCF8d6vGQnNe9Mfhwip1sp AGOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S+vHzL+axkFXm6xp69G0kh3cYsvbHG2zAkh/ccjqW3o=; b=NLqm6E3ZA0Lq4tbJevu86/WdUhvdfzHQDf7yDPznrKNk8e6L2ZZfNfTaZl5h0fle+q CfY3fjBTBDNH0x+yIlugKe943hYWXFrZNHNJX6YuKodgVInCmmjB5LOU5aPXfWNTmX9T gCyhtfT5h/V6DROj0F78hq064j3/DGCwNKK6yzY6ZnzdLDDlZFrEF+6yDSwVORXT7dDH DfoTASul3MbTxlhCbHue+t2LgbYBdnkus0/73DfR4Pon5H+6O8SvxVHR7CXEyBS76Isx Z4iqs8dXb3km3H7JDRaiCXTHGjdVvSfzIxqUlMHfhGVxfwSqgrf2DbtRAcXbPuMGw6bW X8eg== X-Gm-Message-State: AA+aEWZ/+nLmxfkSJwURYT9KMdEiaXSV+TE20WHxgMa93iyzpAUVwct8 E0dQbpZm5BG/uF1ZK47mlu8CZ6F/EPlbgh7pAjZRRTfZbXs= X-Google-Smtp-Source: AFSGD/X/jVPCIYUt6oZYo0UjAR6BhDkRoEsp39Ox5+P/IA1M3UffpHkCxMfXQt7hdkNQDCjJumX0HmY/nZ/msXyx5KU= X-Received: by 2002:a1c:184:: with SMTP id 126mr3011086wmb.24.1542823116362; Wed, 21 Nov 2018 09:58:36 -0800 (PST) MIME-Version: 1.0 References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> <2010C828-FE1A-4500-88A7-F3A809440464@nohats.ca> In-Reply-To: <2010C828-FE1A-4500-88A7-F3A809440464@nohats.ca> From: Warren Kumari Date: Wed, 21 Nov 2018 12:57:59 -0500 Message-ID: To: Paul Wouters Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, "Waltermire, David A." Content-Type: multipart/alternative; boundary="000000000000cd6cd7057b307f08" Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 17:58:51 -0000 --000000000000cd6cd7057b307f08 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 21, 2018 at 12:55 PM Paul Wouters wrote: > On Nov 22, 2018, at 00:03, Warren Kumari wrote: > > > > I am sympathetic to the general use case, but really don't want this to > open scary security holes / decrease "trust" in DNSSEC. > > > By not allowing VPNs to use an enterprise internal dnssec trust anchor, > you also erode trust in dnssec, or end up not using dnssec internally at > all when connected via VPN. > > True. > I suggest you wait for me to push -15 before asking dnsop. It should be > out today or tomorrow and contains quite some changes related to this topic. > Okey dokey, thank you. Please let me know LOUDLY when you have a new version ready (I don't want it to get lost in the post IETF103 / US Thanksgiving holiday / similar shuffle). W > > Paul > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000cd6cd7057b307f08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On We= d, Nov 21, 2018 at 12:55 PM Paul Wouters <paul@nohats.ca> wrote:
<= div dir=3D"auto">On Nov 22, 2018, at 00:03, Warren Kumari <warren@kumari.net> wrote:<= br>



I am sympathetic to the general use case, but really= don't want this to open scary security holes / decrease "trust&qu= ot; in DNSSEC.

By not allowing= VPNs to use an enterprise internal dnssec trust anchor, you also erode tru= st in dnssec, or end up not using dnssec internally at all when connected v= ia VPN.


True.
=C2=A0
=
I suggest you wait for me to push -15 before asking dnsop. It should b= e out today or tomorrow and contains quite some changes related to this top= ic.

Okey dokey, thank you.=C2=A0
Ple= ase let me know LOUDLY when you have a new version ready (I don't want = it to get lost in the post IETF103 / US Thanksgiving holiday / similar shuf= fle).

W

=C2=A0

Paul



--
I don't think = the execution is relevant when it was obviously a bad idea in the first pla= ce.
This is like putting rabid weasels in your pants, and later expressi= ng regret at having chosen those particular rabid weasels and that pair of = pants.
=C2=A0 =C2=A0---maf
--000000000000cd6cd7057b307f08-- From nobody Wed Nov 21 10:19:01 2018 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 C1EAB130F13; Wed, 21 Nov 2018 10:18:41 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, 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 S4N3UcfRuJjl; Wed, 21 Nov 2018 10:18:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1CA130F17; Wed, 21 Nov 2018 10:18:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CAD8220089; Wed, 21 Nov 2018 13:18:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3EE18BD3; Wed, 21 Nov 2018 13:18:36 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CEDA18B; Wed, 21 Nov 2018 13:18:36 -0500 (EST) From: Michael Richardson To: Warren Kumari cc: Paul Wouters , ipsec@ietf.org, ipsecme-chairs@ietf.org, "Waltermire\, David A." , The IESG , draft-ietf-ipsecme-split-dns@ietf.org In-Reply-To: References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <3734030E-4394-4C1A-9FE7-493FF5EC7FED@nohats.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 18:18:51 -0000 --=-=-= Content-Type: text/plain {sorry to re-interate, and/or beat what might be a dead horse already} Warren Kumari wrote: > So, I'm still fairly uncomfortable - having a VPN provider able to > override my DNSSEC configuration worries me, especially if things like > TLSA / DNSSEC Chain Extension / similar are used. > I was starting to come to terms with this, as I'd assumed that the > common deployment scenario was "Install (as root / admin) this binary > package containing a VPN client.", in which case a malicious VPN > provider already has the ability to do, well, basically anything (and > doesn't need this method to be malicious), but if this isn't the > universal case, I'm concerned again... It's more of the: "Install (as root / admin) this binary package containing an *IKEv2* VPN client." and this just does not apply to 90% of the non-Enterprise use cases, because they aren't using IKEv2 anyway. The places where you should have a concern are: 1) iOS, Android phones, Linux/MacOS desktops, running the OS-provided IKEv2/IPsec client. 2) installing an opaque (to the end user) configuration blob. - configuration blob enables DNSSEC and INTERNAL_DNS configuration support 3) connecting to a non-Enterprise VPN supplier, or to an Enterprise that does not already own (p0wn) the device you are using (i.e. BYOD). I omit windows desktop VPN (even if it's IPsec), because in practice there is always a binary install of some kind, despite decades of trying to do otherwise. (This in itself should make the IESG sad) Note if (2) is not true, that is, the end user is loading .p12 files, and setting up policies in some semi-manual fashion (IKEv2 lets us automate a great deal of the policy), then the dialog ought to have some way for a knowledgeable user to decline and/or whitelist the DNSSEC overrides. A non-knowledgeable user is going to be loading a configuration blob. Potentially, there might be validation on the contents of that, and whatever DNSSEC whitelisting is going to occur. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv1oXsACgkQgItw+93Q 3WW3xggAuAjZG1p/KZnN/99ZfL/L+rx5+of8d0wLT56oCNLGXdI9mRIgQ8qGp9NX EVbr+GEyLRtEGHGagigC/j/7mEtPyeFtuDufhvIRvZ7pfBSearXSn9sJJYI38emO 0ZN1hHMYSsfLG3G0KebtNVDX4ZWVJ0+VEQQ70PUkseWjz89qMT+S/M9y7CDv6pOa QArhr7se6L/XPKEPe6qcpeBNA3AlD0wzIdq4j/Ea1Z51Vek38rnnenDOQlog/iqJ lB1B9dYjY2xlbWA8WgqzBKM2dNL4TcEMUNphENfYzbrcI0mix3iX8E0onaxikc3s cva7u3+fDehnMpzcCwo0zo739TySIA== =+rQF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 21 10:25:42 2018 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 893C9130DDC; Wed, 21 Nov 2018 10:25:33 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, 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 OdoEksXDZboR; Wed, 21 Nov 2018 10:25:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F11A1294D0; Wed, 21 Nov 2018 10:25:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 676B720089; Wed, 21 Nov 2018 13:25:25 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D20A6BD3; Wed, 21 Nov 2018 13:25:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFC5218B; Wed, 21 Nov 2018 13:25:29 -0500 (EST) From: Michael Richardson To: Paul Wouters cc: Warren Kumari , ipsec@ietf.org, The IESG In-Reply-To: <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 18:25:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> Sadly, very few regular users use IPsec/IKEv2 for this kind of acces= s. > This is very incorrect. > Almost all VPN providers for apple (OSX and iOS) use IKEv2 with > CP. Based on numbers of concurrent users I have seen from some vendors > using libreswan, we are talking in the orders of 100=E2=80=99s of tho= usands of > users. That's awesome news to learn!!! I haven't seen this in the wild myself, and it's not the case in Android as you point out. > One of the main reasons: MOBIKE with phones using wifi and 4/5G and > network switching. So that's a good really good result. Kudos. Sometimes the tortoise does win the race with better technology. > For Android, the situation is bad. Due to the OS not properly > supporting IKEv2, most VPN services bundle openvpn apps for android a= nd > very few bundle strongswan with its userland ESP that can do IKEv2. I'm aware that they (Android) were thinking about fixing this, but nothing has happened yet to my knowledge. >> In almost all cases the VPN provider is in control of the software t= hat is >> installed on the client system, so they can hijack paypal already. > This is also incorrect. All OSX and iOS provisioning happens via > .mobileconfig profiles or apps using apple API=E2=80=99s that are I'm talking here about people using VPNConnect, OpenConnect, some .MSI that actually installs OpenVPN on windows, etc. >> But, this seems terribly unlikely since just getting two VPNs instal= led >> (and compatible) and running at the same time is such deep VPN-fu, t= hat it's >> like only half the IPsec WG members that could ever make this work a= nyway. > It is currently uncommon indeed but I think and hope we will see more > of this, especially when we all want a continuous VPN link up to our > home network. I also want it to be easier. I see IPv6 for the Enterprise remote-access VPN as instrumental to making this happen. Each Enterprise can embed their IPv4 RFC1918 address space in= to a unique IPv6 prefix, and can NAT64 to get to actual internal legacy servic= es if they have to. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlv1oxkACgkQgItw+93Q 3WVvQwgAuVF7mgu6R9TWU/rL0RovxAzxANwtDihslfbhgj5r1yGUIlFY/Cy/sX/j mgXzlU56vXWeJEJVzAEV78LoXl2Dg/LQ0sVIDvaQR1yObMbhf0zf/klBBT/uEu7d w69aYF3N3Xe6UFJkd+nzpSMgTdpcT34JAbxUxdadRdNxH9458CO+CypCWqAHXqbF JwV0OaXvoTKTf+PaUypUlmIJVg58v07AHSgSoJbtUDaXffq+aK0zhx7f2XMXM0G9 YmwPITqThnVsMePzCJf8EkniZXjqtXJIaggqEVF3vYgGsiNY4ycqxIVn1FjhrIrv VF5PwzrcXur80jFDe1lHh5MAsIoPeA== =DhZ5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 21 12:55:45 2018 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 92BE6130DC5; Wed, 21 Nov 2018 12:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org 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 0zDYNwo_prYF; Wed, 21 Nov 2018 12:55:32 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (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 56A2C12F295; Wed, 21 Nov 2018 12:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rCTr7QYQw73tQED8o5983ldZgcWn714Z/PFWiQ9drIQ=; b=iXGWZZGbFfJBNdfzPzzyshkPRF 1mknDmiRKnhR4HmQHADYdUmXhKO/F3rm5Peiu3rO7W07bjWAGQ4ZeNDga3QbTOXUdDkY1hGjKoJSc Tb6in7QW5VCd301GZ4wLPxxbQBOx5fnTjf8/KveRtTt11bWh9TpvaiYgj97ETN1nXgcA=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1gPZWz-0000vk-SS; Wed, 21 Nov 2018 20:55:29 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id DB2257A2EA3; Wed, 21 Nov 2018 15:55:28 -0500 (EST) Date: Wed, 21 Nov 2018 15:55:28 -0500 From: "Theodore Y. Ts'o" To: Michael Richardson Cc: Paul Wouters , ipsec@ietf.org, Warren Kumari , The IESG Message-ID: <20181121205528.GI26006@thunk.org> References: <154275299932.29937.5149382512933072864.idtracker@ietfa.amsl.com> <25704.1542816043@localhost> <3A9700FB-EF0B-415B-9338-72070DE8A335@nohats.ca> <31884.1542824729@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31884.1542824729@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 20:55:34 -0000 On Wed, Nov 21, 2018 at 01:25:29PM -0500, Michael Richardson wrote: > > > Almost all VPN providers for apple (OSX and iOS) use IKEv2 with > > CP. Based on numbers of concurrent users I have seen from some vendors > > using libreswan, we are talking in the orders of 100’s of thousands of > > users. > > That's awesome news to learn!!! > I haven't seen this in the wild myself, and it's not the case in Android as > you point out. FWIW, I use Private Interent Access (privateinternetaccess.com), and while it's "user friendly Linux install is effectively "curl | sudo /bin/sh" it did have a manual install procedure, and all the manual install procedure did was install the package network-manager-openvpn-gnome and then make configuration changes to Network Manager so it new where to find the PIA servers. So yes, no VPN software was downloaded, and while you could argue that if most users are trusting a "curl .... | sudo /bin/sh" install, there are plenty of ways for a VPN provider to completely take over your machine (never mind your DNS!), at least a security expert can audit the script, and someone who is sufficiently paranoid can run the commands and/or edit the config files by hand. Cheers, - Ted From nobody Wed Nov 21 22:27:40 2018 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 15174130DFC; Wed, 21 Nov 2018 22:27:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154286805405.5246.1218406478807265370@ietfa.amsl.com> Date: Wed, 21 Nov 2018 22:27:34 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-15.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 06:27:34 -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 WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-15.txt Pages : 15 Date : 2018-11-21 Abstract: This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol Version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split tunnel configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-15 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-15 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 Sat Nov 24 13:16:04 2018 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 BCFD3130FB8; Sat, 24 Nov 2018 13:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 eIulm-zgdnwT; Sat, 24 Nov 2018 13:15:53 -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 972E0130DF5; Sat, 24 Nov 2018 13:15:51 -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 wAOLFkxs012548 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Nov 2018 23:15:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wAOLFkut008736; Sat, 24 Nov 2018 23:15:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23545.49026.588213.633610@fireball.acr.fi> Date: Sat, 24 Nov 2018 23:15:46 +0200 From: Tero Kivinen To: Paul Wouters Cc: Spencer Dawkins , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, The IESG In-Reply-To: References: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 11 min Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 21:15:56 -0000 Paul Wouters writes: > So I suggest instead: > > A client using these configuration payloads will be able to request > and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN > and INTERNAL_DNSSEC_TA configuration attributes. These attributes > MUST be accompanied by one or more INTERNAL_IP4_DNS or > INTERNAL_IP6_DNS configuration attributes. The client device can > then use the internal DNS server(s) for any DNS queries within the > assigned domains. DNS queries for other domains MUST be sent to the > regular DNS service of the client. So the meaning of the INTERNAL_IP*_DNS changs meaning depending whether you have INTERNAL_DNS_DOMAIN or not. You might want to be bit more text explaining that in this paragraph. Currently if server send INTERNAL_IP*_DNS (and do not include INTERNAL_DNS_DOMAIN), then clients usually send all dns queries to that server. Typically enterprice users trust their own DNS servers more than the DNS server provided by the hotel... After this change client must have some other DNS server also configured, and MUST use them for other domains. Of course the general idea for the Split-DNS is that we do not send all dns traffic to server, only those internal domains, but one main use for it is also to provide TAs for those internal domains so DANE etc can work for internal services. Anyways I think changing that to say "SHOULD be sent" could work better, i.e., depending on the policy clients could either send requests to normal DNS server or to the server provided in IKE. Note, that the original configuration payload was supposed to provide similar information than what DHCP does, so client does not need to have anything preconfigured, but can get the whole network configuration from the server. This included addresses, dns servers, etc, and even DHCP server address that it can use to get attributes not included in the configuration payload. Usually the configuration parameters received from configuration payload replaced the parameters they had before. -- kivinen@iki.fi From nobody Sun Nov 25 22:56:28 2018 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 D0F7D1294D7; Sun, 25 Nov 2018 22:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Frc77s4vjf7A; Sun, 25 Nov 2018 22:56:24 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EA8128CB7; Sun, 25 Nov 2018 22:56:24 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 10C4430841DE; Mon, 26 Nov 2018 06:56:24 +0000 (UTC) Received: from thinkpad.nohats.ca (ovpn-204-27.brq.redhat.com [10.40.204.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3FC355D9C6; Mon, 26 Nov 2018 06:56:19 +0000 (UTC) To: Tero Kivinen , Paul Wouters Cc: Spencer Dawkins , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, The IESG References: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> <23545.49026.588213.633610@fireball.acr.fi> From: Paul Wouters Message-ID: <6cf92ec6-0ffd-9864-0793-bbf30fb638ae@redhat.com> Date: Mon, 26 Nov 2018 13:56:17 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <23545.49026.588213.633610@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 26 Nov 2018 06:56:24 +0000 (UTC) Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 06:56:27 -0000 On 2018-11-25 4:15 a.m., Tero Kivinen wrote: > Paul Wouters writes: >> So I suggest instead: >> >> A client using these configuration payloads will be able to request >> and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN >> and INTERNAL_DNSSEC_TA configuration attributes. These attributes >> MUST be accompanied by one or more INTERNAL_IP4_DNS or >> INTERNAL_IP6_DNS configuration attributes. The client device can >> then use the internal DNS server(s) for any DNS queries within the >> assigned domains. DNS queries for other domains MUST be sent to the >> regular DNS service of the client. > So the meaning of the INTERNAL_IP*_DNS changs meaning depending > whether you have INTERNAL_DNS_DOMAIN or not. You might want to be bit > more text explaining that in this paragraph. I did not really want to do that. It would also require updating RFC 7296. So instead, I just pushed a change with: -   assigned domains.  DNS queries for other domains MUST be sent to the -   regular DNS service of the client. +   assigned domains.  DNS queries for other domains SHOULD be sent to +   the regular DNS service of the client unless it prefers to use the +   IPsec tunnel for all its DNS queries.  For example, the client could +   trust the IPsec provided DNS servers more than the locally provided +   DNS servers especially in the case of connecting to unknown or +   untrusted networks (eg coffee shops or hotel networks).  Or the +   client could prefer the IPsec based DNS servers because those provide +   additional features over the local DNS servers. > Anyways I think changing that to say "SHOULD be sent" could work > better, i.e., depending on the policy clients could either send > requests to normal DNS server or to the server provided in IKE. Yes, done. see above. > > Note, that the original configuration payload was supposed to provide > similar information than what DHCP does, so client does not need to > have anything preconfigured, but can get the whole network > configuration from the server. This included addresses, dns servers, > etc, and even DHCP server address that it can use to get attributes > not included in the configuration payload. Usually the configuration > parameters received from configuration payload replaced the parameters > they had before. Yes, but with split-tunnel, the client is clearly stepping in with one foot while keeping the other foot dry :) Paul From nobody Sun Nov 25 23:02:59 2018 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 C50031274D0; Sun, 25 Nov 2018 23:02:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154321577675.24453.9772819866712045004@ietfa.amsl.com> Date: Sun, 25 Nov 2018 23:02:56 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-16.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 07:02:57 -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 WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-16.txt Pages : 15 Date : 2018-11-25 Abstract: This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol Version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split tunnel configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-16 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-16 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 Nov 27 05:23:53 2018 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 34316130EAE; Tue, 27 Nov 2018 05:23:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c5pZ_e8brDnT; Tue, 27 Nov 2018 05:23:34 -0800 (PST) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 34695130EA0; Tue, 27 Nov 2018 05:23:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 2DF3220099; Tue, 27 Nov 2018 14:23:31 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JFrBUILKhfKd; Tue, 27 Nov 2018 14:23:31 +0100 (CET) Received: from inf-205-3.inf.um.es (inf-205-3.inf.um.es [155.54.205.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 50B4E1FFCB; Tue, 27 Nov 2018 14:23:29 +0100 (CET) From: Gabriel Lopez Message-Id: <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_C06730B5-BD05-4166-87B8-DDC1F4254512" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 27 Nov 2018 14:23:28 +0100 In-Reply-To: Cc: Gabriel Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez To: Paul Wouters References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 13:23:46 -0000 --Apple-Mail=_C06730B5-BD05-4166-87B8-DDC1F4254512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, all Please find attached some answers to your comments. Let=E2=80=99s go = section by section, it will be easier to follow the discussion. > El 18 nov 2018, a las 7:52, Paul Wouters escribi=C3=B3:= >=20 >=20 >=20 >=20 >=20 > General comments: > I'd like to see "Case 1" and "Case 2" replaced with more descriptive = terms. I keep losing track of which case is which. > Perhaps call them IKE Case and IKE-less Case ? [Authors] We agree. What about "IKE-full" and "IKE-less" cases? >=20 >=20 > Section 1: >=20 > Typically, traditional IPsec VPN concentrators and, in general, > entities (i.e. hosts or security gateways) supporting IKE/IPsec, = must > be configured directly by the administrator. This makes the IPsec > security association (SA) management difficult and generates a lack > of flexibility, specially if the number of security policies and SAs > to handle is high. >=20 > This is not entirely true. We have Opportunistic IPsec that automates > this precisely for the same reasons. We also have packet triggers in > combination with Traffic Selector narrowing to create multiple IPsec > SA's on demand. I know this is all qualified by "typically" but I = think > this paragraph is not adding any real information. The idea is that we > have an SDWAN situation with SDN controllers and nodes, and we want to > automate the IKE/IPsec for that specific deployment use case. [Authors] Thanks for the suggestion. Certainly the text is not = reflecting the existence of those techniques alleviating the task of = establishing IPsec SAs. Nonetheless, we have to clarify that this draft = is not only guided by the SDWAN scenario and, in fact, it is intended to = be applicable in other foreseeable SDN deployments. With this in mind, = we propose the following changes in the text: s/"Typically, traditional IPsec VPN concentrators and, in general, entities (i.e. hosts or security gateways) supporting IKE/IPsec, must be configured directly by the administrator. This makes the IPsec security association (SA) management difficult and generates a lack of flexibility, specially if the number of security policies and SAs to handle is high. With the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant. Thus, the SDN-based service described in this document will autonomously deal with IPsec SAs management." / =20 "With the growth of SDN-based scenarios where network resources are deployed in an autonomous manner, a mechanism to manage IPsec SAs according to the SDN architecture becomes more relevant." =09 s/"An example of usage can be the notion of Software Defined WAN (SD- WAN), SDN extension providing a software abstraction to create secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsec as underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services." / =20 "An example of usage can be the notion of Software Defined WAN (SD- WAN), SDN extension providing a software abstraction to create secure network overlays over traditional WAN and branch networks. SD-WAN is based on IPsec as underlying security protocol and aims to provide flexible, automated, fast deployment and on-demand security network services. Other examples are host-to-host or full-mesh encryption.=20 Thus, the SDN-based service described in this document will = autonomously deal with IPsec=20 SAs management. >=20 >=20 > The analysis of the host-to-gateway (roadwarrior) scenario is TBD. >=20 > Does this sentence mean this is to be done in this document or is it = out > of scope for this document (but it does allow it to be added later) ? [Authors] We do not see a clear use case for roadwarrior scenarios based = on SDN, the proposal is to remove it from this document.=20 Regards, Gabi. >=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 --Apple-Mail=_C06730B5-BD05-4166-87B8-DDC1F4254512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Paul, all

Please find attached = some answers to your comments. Let=E2=80=99s go section by section, it = will be easier to follow the discussion.


El 18 nov 2018, a las 7:52, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:





General comments:
I'd like to = see "Case 1" and "Case 2" replaced with more descriptive terms. I keep = losing track of which case is which.
Perhaps call them IKE = Case and IKE-less Case ?

[Authors] We agree. What about "IKE-full" and = "IKE-less" cases?



Section 1:

=   Typically, traditional IPsec VPN concentrators and, in = general,
  entities (i.e. hosts or security = gateways) supporting IKE/IPsec, must
  be = configured directly by the administrator.  This makes the IPsec
  security association (SA) management difficult = and generates a lack
  of flexibility, = specially if the number of security policies and SAs
=   to handle is high.

This is not = entirely true. We have Opportunistic IPsec that automates
this precisely for the same reasons. We also have packet = triggers in
combination with Traffic Selector narrowing to = create multiple IPsec
SA's on demand. I know this is all = qualified by "typically" but I think
this paragraph is not = adding any real information. The idea is that we
have an = SDWAN situation with SDN controllers and nodes, and we want to
automate the IKE/IPsec for that specific deployment use = case.



[Authors]  Thanks for the suggestion. = Certainly the text is not reflecting the existence of those techniques = alleviating the task of establishing IPsec SAs. Nonetheless, we have to = clarify that this draft is not only guided by the SDWAN scenario and, in = fact, it is intended to be applicable in other foreseeable SDN = deployments.  With this in mind, we propose the following changes = in the text:


s/"Typically, traditional IPsec VPN concentrators = and, in general,
   entities (i.e. hosts or security = gateways) supporting IKE/IPsec, must
   be = configured directly by the administrator.  This makes the = IPsec
   security association (SA) management = difficult and generates a lack
   of flexibility, = specially if the number of security policies and SAs
  =  to handle is high.  With the growth of SDN-based scenarios = where
   network resources are deployed in an = autonomous manner, a mechanism
   to manage IPsec = SAs according to the SDN architecture becomes more
  =  relevant.  Thus, the SDN-based service described in this = document
   will autonomously deal with IPsec SAs = management." /
   
   "With the = growth of SDN-based scenarios where
   network = resources are deployed in an autonomous manner, a = mechanism
   to manage IPsec SAs according to the = SDN architecture becomes more
  =  relevant."
   
s/"An example of usage = can be the notion of Software Defined WAN (SD-
  =  WAN), SDN extension providing a software abstraction to create = secure
   network overlays over traditional WAN and = branch networks.  SD-WAN is
   based on IPsec = as underlying security protocol and aims to provide
  =  flexible, automated, fast deployment and on-demand security = network
   services." /
  =  
   "An example of usage can be the notion of = Software Defined WAN (SD-
   WAN), SDN extension = providing a software abstraction to create secure
  =  network overlays over traditional WAN and branch networks. =  SD-WAN is
   based on IPsec as underlying = security protocol and aims to provide
   flexible, = automated, fast deployment and on-demand security = network
   services. Other examples are host-to-host = or full-mesh encryption. 
   Thus, the = SDN-based service described in this document will autonomously deal with = IPsec 
   SAs management.



  The analysis of = the host-to-gateway (roadwarrior) scenario is TBD.

Does this sentence mean this is to be done in this document = or is it out
of scope for this document (but it does allow = it to be added later) ?


[Authors] We do not see = a clear use case for roadwarrior scenarios based on SDN, the = proposal
  is to remove it from this = document. 



Regards, = Gabi.




-----------------------------------------------------------
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=_C06730B5-BD05-4166-87B8-DDC1F4254512-- From nobody Tue Nov 27 05:34:16 2018 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 19582130DE2; Tue, 27 Nov 2018 05:34:14 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 tnxV6Mxjkh_W; Tue, 27 Nov 2018 05:34: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 5EB01127133; Tue, 27 Nov 2018 05:34:11 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4344WN0C78zFV2; Tue, 27 Nov 2018 14:34:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543325648; bh=5tYSqhBCHOwxcIy8Tr5IkFuCZEQo5+xYWgITFF6HkvE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ivbNEPrV5cHEkGUHboEdyZoQi7O7rENVPNXk/OS/bX4YAltTsEnwP97GsyGfZpREm bzs6KTJSg5S11fTC763yvCMeclOmpLgxm25AkrVXtnHUrarreqWZNUN5zqFvR2e8Mj TJ1qLy+UhkmuAzGfXWLVkgzhr4WbRG9rdffM3gNc= 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 Y4fqUw_vOX0l; Tue, 27 Nov 2018 14:34:06 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 27 Nov 2018 14:34:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 054D44A2C76; Tue, 27 Nov 2018 08:34:03 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 054D44A2C76 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EEE0041C3B27; Tue, 27 Nov 2018 08:34:03 -0500 (EST) Date: Tue, 27 Nov 2018 08:34:03 -0500 (EST) From: Paul Wouters To: Gabriel Lopez cc: i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez , Yoav Nir In-Reply-To: <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> Message-ID: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 13:34:14 -0000 On Tue, 27 Nov 2018, Gabriel Lopez wrote: > Hi Paul, all > > Please find attached some answers to your comments. Let’s go section by section, it will be easier to follow the discussion. > > > El 18 nov 2018, a las 7:52, Paul Wouters escribió: > > > General comments: > I'd like to see "Case 1" and "Case 2" replaced with more descriptive terms. I keep losing track of which case is which. > Perhaps call them IKE Case and IKE-less Case ? > > > [Authors] We agree. What about "IKE-full" and "IKE-less" cases? Hmm, I find "IKE-full" a bit odd (also because in English you would probably say "full-IKE" and not "IKE-full". Maybe another word could be "IKE-managed" or "IKE-controled" or "IKE-delegated" ? > [Authors]  Thanks for the suggestion. Certainly the text is not reflecting the existence of those techniques alleviating the task of establishing IPsec SAs. Nonetheless, > we have to clarify that this draft is not only guided by the SDWAN scenario and, in fact, it is intended to be applicable in other foreseeable SDN deployments.  With > this in mind, we propose the following changes in the text: > > > s/"Typically, traditional IPsec VPN concentrators and, in general, >    entities (i.e. hosts or security gateways) supporting IKE/IPsec, must >    be configured directly by the administrator.  This makes the IPsec >    security association (SA) management difficult and generates a lack >    of flexibility, specially if the number of security policies and SAs >    to handle is high.  With the growth of SDN-based scenarios where >    network resources are deployed in an autonomous manner, a mechanism >    to manage IPsec SAs according to the SDN architecture becomes more >    relevant.  Thus, the SDN-based service described in this document >    will autonomously deal with IPsec SAs management." / >     >    "With the growth of SDN-based scenarios where >    network resources are deployed in an autonomous manner, a mechanism >    to manage IPsec SAs according to the SDN architecture becomes more >    relevant." >     > s/"An example of usage can be the notion of Software Defined WAN (SD- >    WAN), SDN extension providing a software abstraction to create secure >    network overlays over traditional WAN and branch networks.  SD-WAN is >    based on IPsec as underlying security protocol and aims to provide >    flexible, automated, fast deployment and on-demand security network >    services." / >     >    "An example of usage can be the notion of Software Defined WAN (SD- >    WAN), SDN extension providing a software abstraction to create secure >    network overlays over traditional WAN and branch networks.  SD-WAN is >    based on IPsec as underlying security protocol and aims to provide >    flexible, automated, fast deployment and on-demand security network >    services. Other examples are host-to-host or full-mesh encryption.  >    Thus, the SDN-based service described in this document will autonomously deal with IPsec  >    SAs management. works for me. >   The analysis of the host-to-gateway (roadwarrior) scenario is TBD. > > Does this sentence mean this is to be done in this document or is it out > of scope for this document (but it does allow it to be added later) ? > > [Authors] We do not see a clear use case for roadwarrior scenarios based on SDN, the proposal >   is to remove it from this document.  The case I can think of is if this is a "site to site" connection but one site is on dynamic IP (eg cable modem or 4g/5g connection) ? The only difference in yang would be to instead of a static ip or hostname, to also allow a value of "any IP". In libreswan we use the string "%any" (and %any4 or %any6) but one could also use 0.0.0.0 to mean that. I don't think it needs any other special handling (other then making sure an endpoint 0.0.0.0 should not use an IP based identity. Paul From nobody Tue Nov 27 07:28:10 2018 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 4842312D4E7; Tue, 27 Nov 2018 07:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ad5pBlpIuouN; Tue, 27 Nov 2018 07:27:59 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 48666130DDA; Tue, 27 Nov 2018 07:27:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CBDD01FE6F; Tue, 27 Nov 2018 16:27:53 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WJK62bvlgmTP; Tue, 27 Nov 2018 16:27:53 +0100 (CET) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 07E071FFD4; Tue, 27 Nov 2018 16:27:50 +0100 (CET) From: Rafa Marin-Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_66109275-53AA-4055-94F2-8800E1AEC71B" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 27 Nov 2018 16:27:49 +0100 In-Reply-To: Cc: Rafa Marin-Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" To: Paul Wouters References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 15:28:03 -0000 --Apple-Mail=_66109275-53AA-4055-94F2-8800E1AEC71B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul: > Section 3: >=20 > It requires information about the > required authentication method (i.e. preshared keys), DH groups, > modes and algorithms for IKE SA negotiation, etc. >=20 > In the IKE world, we really try to not recommend preshared keys, = because > these keys mostly based on human readable low entropy content. If this > document thinks raw RSA/ECDSA keys or X.509 certificates are also = methods > that will be implemented by SDN Controllers, please change the example = of > preshared keys to something else. [Authors] In IKE case, the Security Controller generates pseudo-random = PSKs. Hence, there is NO low entropy=20 content since this PSK is not based on human involment. Having said = that, raw RSA/ECDSA keys or X.509 certificates are plausible. Let's add it: "It requires information about the required authentication method (i.e. a raw public key, a x509 = certificate or preshared keys), DH groups, modes and algorithms for IKE SA negotiation, etc.=E2=80=9D Best Regards. ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_66109275-53AA-4055-94F2-8800E1AEC71B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul:

Section 3:

    It requires information about the
    required authentication method (i.e. = preshared keys), DH groups,
    modes = and algorithms for IKE SA negotiation, etc.

In the IKE world, we really try to not recommend preshared = keys, because
these keys mostly based on human readable = low entropy content. If this
document thinks raw RSA/ECDSA = keys or X.509 certificates are also methods
that will be = implemented by SDN Controllers, please change the example of
preshared keys to something else.

[Authors] In IKE case, the Security = Controller generates pseudo-random PSKs. Hence, there is NO low = entropy 
content since this PSK is not based on human = involment. Having said that, raw RSA/ECDSA keys or
X.509 = certificates are plausible. Let's add it:

    "It requires information about = the
    required authentication method (i.e. a raw = public key, a x509 certificate or preshared keys), DH = groups,
    modes and algorithms for IKE SA = negotiation, etc.=E2=80=9D

Best = Regards.


-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_66109275-53AA-4055-94F2-8800E1AEC71B-- From nobody Tue Nov 27 08:53:13 2018 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 BDD4612D4EA; Tue, 27 Nov 2018 08:53:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gy7nKXuAlT-O; Tue, 27 Nov 2018 08:53:04 -0800 (PST) Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id D339C126BED; Tue, 27 Nov 2018 08:53:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id C00302015D; Tue, 27 Nov 2018 17:53:02 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kfR7t4gZpR_4; Tue, 27 Nov 2018 17:53:02 +0100 (CET) Received: from inf-205-3.inf.um.es (inf-205-3.inf.um.es [155.54.205.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 954DA1FEDD; Tue, 27 Nov 2018 17:53:00 +0100 (CET) From: Gabriel Lopez Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CA24D225-DC26-48B0-902D-D3617FAEBDB6" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 27 Nov 2018 17:52:58 +0100 In-Reply-To: Cc: Gabriel Lopez , i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez , Yoav Nir To: Paul Wouters References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 16:53:07 -0000 --Apple-Mail=_CA24D225-DC26-48B0-902D-D3617FAEBDB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, > El 27 nov 2018, a las 14:34, Paul Wouters escribi=C3=B3= : >=20 > On Tue, 27 Nov 2018, Gabriel Lopez wrote: >=20 >> Hi Paul, all >> Please find attached some answers to your comments. Let=E2=80=99s go = section by section, it will be easier to follow the discussion. >>=20 >> El 18 nov 2018, a las 7:52, Paul Wouters = escribi=C3=B3: >> General comments: >> I'd like to see "Case 1" and "Case 2" replaced with more descriptive = terms. I keep losing track of which case is which. >> Perhaps call them IKE Case and IKE-less Case ? >> [Authors] We agree. What about "IKE-full" and "IKE-less" cases? >=20 > Hmm, I find "IKE-full" a bit odd (also because in English you would > probably say "full-IKE" and not "IKE-full". Maybe another word could > be "IKE-managed" or "IKE-controled" or "IKE-delegated=E2=80=9D ? Let=E2=80=99s use then IKE and IKE-less cases. Is that ok? >=20 >> [Authors] Thanks for the suggestion. Certainly the text is not = reflecting the existence of those techniques alleviating the task of = establishing IPsec SAs. Nonetheless, >> we have to clarify that this draft is not only guided by the SDWAN = scenario and, in fact, it is intended to be applicable in other = foreseeable SDN deployments. With >> this in mind, we propose the following changes in the text: >> s/"Typically, traditional IPsec VPN concentrators and, in general, >> entities (i.e. hosts or security gateways) supporting IKE/IPsec, = must >> be configured directly by the administrator. This makes the IPsec >> security association (SA) management difficult and generates a = lack >> of flexibility, specially if the number of security policies and = SAs >> to handle is high. With the growth of SDN-based scenarios where >> network resources are deployed in an autonomous manner, a = mechanism >> to manage IPsec SAs according to the SDN architecture becomes more >> relevant. Thus, the SDN-based service described in this document >> will autonomously deal with IPsec SAs management." / >> =20 >> "With the growth of SDN-based scenarios where >> network resources are deployed in an autonomous manner, a = mechanism >> to manage IPsec SAs according to the SDN architecture becomes more >> relevant." >> =20 >> s/"An example of usage can be the notion of Software Defined WAN (SD- >> WAN), SDN extension providing a software abstraction to create = secure >> network overlays over traditional WAN and branch networks. SD-WAN = is >> based on IPsec as underlying security protocol and aims to provide >> flexible, automated, fast deployment and on-demand security = network >> services." / >> =20 >> "An example of usage can be the notion of Software Defined WAN = (SD- >> WAN), SDN extension providing a software abstraction to create = secure >> network overlays over traditional WAN and branch networks. SD-WAN = is >> based on IPsec as underlying security protocol and aims to provide >> flexible, automated, fast deployment and on-demand security = network >> services. Other examples are host-to-host or full-mesh encryption.=20= >> Thus, the SDN-based service described in this document will = autonomously deal with IPsec=20 >> SAs management. >=20 > works for me. >=20 >> The analysis of the host-to-gateway (roadwarrior) scenario is = TBD. >>=20 >> Does this sentence mean this is to be done in this document or = is it out >> of scope for this document (but it does allow it to be added = later) ? >> [Authors] We do not see a clear use case for roadwarrior scenarios = based on SDN, the proposal >> is to remove it from this document.=20 >=20 > The case I can think of is if this is a "site to site" connection but > one site is on dynamic IP (eg cable modem or 4g/5g connection) ? >=20 > The only difference in yang would be to instead of a static ip or > hostname, to also allow a value of "any IP". In libreswan we use > the string "%any" (and %any4 or %any6) but one could also use 0.0.0.0 > to mean that. I don't think it needs any other special handling (other > then making sure an endpoint 0.0.0.0 should not use an IP based > identity. ok, that can be supported by the model without the necessity to include = the specific road warrior scenario. BTW, Fernando Pere=C3=B1iguez is helping with the review. Our plan is to = add him as author in the next version. >=20 > Paul ----------------------------------------------------------- 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=_CA24D225-DC26-48B0-902D-D3617FAEBDB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul,

El 27 nov 2018, a las 14:34, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:

On Tue, 27 Nov 2018, Gabriel Lopez wrote:

Hi Paul, = all
Please find attached some answers to your comments. = Let=E2=80=99s go section by section, it will be easier to follow the = discussion.

=      El 18 nov 2018, a las 7:52, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:
General comments:
I'd like to = see "Case 1" and "Case 2" replaced with more descriptive terms. I keep = losing track of which case is which.
Perhaps call them IKE = Case and IKE-less Case ?
[Authors] We agree. What about = "IKE-full" and "IKE-less" cases?

Hmm, I find "IKE-full" a bit odd (also because in English you = would
probably say "full-IKE" and not "IKE-full". Maybe = another word could
be "IKE-managed" or "IKE-controled" or = "IKE-delegated=E2=80=9D ?


Let=E2=80=99s use then IKE = and IKE-less cases. Is that ok?


[Authors]  Thanks = for the suggestion. Certainly the text is not reflecting the existence = of those techniques alleviating the task of establishing IPsec SAs. = Nonetheless,
we have to clarify that this draft is not = only guided by the SDWAN scenario and, in fact, it is intended to be = applicable in other foreseeable SDN deployments.  With
this in mind, we propose the following changes in the = text:
s/"Typically, traditional IPsec VPN concentrators = and, in general,
   entities (i.e. hosts or = security gateways) supporting IKE/IPsec, must
  =  be configured directly by the administrator.  This makes the = IPsec
   security association (SA) management = difficult and generates a lack
   of = flexibility, specially if the number of security policies and SAs
   to handle is high.  With the growth of = SDN-based scenarios where
   network resources = are deployed in an autonomous manner, a mechanism
  =  to manage IPsec SAs according to the SDN architecture becomes = more
   relevant.  Thus, the SDN-based = service described in this document
   will = autonomously deal with IPsec SAs management." /
  =  
   "With the growth of SDN-based = scenarios where
   network resources are = deployed in an autonomous manner, a mechanism
  =  to manage IPsec SAs according to the SDN architecture becomes = more
   relevant."
  =  
s/"An example of usage can be the notion of = Software Defined WAN (SD-
   WAN), SDN extension = providing a software abstraction to create secure
  =  network overlays over traditional WAN and branch networks. =  SD-WAN is
   based on IPsec as underlying = security protocol and aims to provide
  =  flexible, automated, fast deployment and on-demand security = network
   services." /
  =  
   "An example of usage can be the notion = of Software Defined WAN (SD-
   WAN), SDN = extension providing a software abstraction to create secure
   network overlays over traditional WAN and branch = networks.  SD-WAN is
   based on IPsec as = underlying security protocol and aims to provide
  =  flexible, automated, fast deployment and on-demand security = network
   services. Other examples are = host-to-host or full-mesh encryption. 
  =  Thus, the SDN-based service described in this document will = autonomously deal with IPsec 
   SAs = management.

works for me.

=        The analysis of the = host-to-gateway (roadwarrior) scenario is TBD.

     Does this sentence mean this = is to be done in this document or is it out
=      of scope for this document (but it does = allow it to be added later) ?
[Authors] We do not see a = clear use case for roadwarrior scenarios based on SDN, the proposal
  is to remove it from this document. 

The case I can think of is if = this is a "site to site" connection but
one site is on = dynamic IP (eg cable modem or 4g/5g connection) ?

The only difference in yang would be to instead of a static = ip or
hostname, to also allow a value of "any IP". In = libreswan we use
the string "%any" (and %any4 or %any6) = but one could also use 0.0.0.0
to mean that. I don't think = it needs any other special handling (other
then making = sure an endpoint 0.0.0.0 should not use an IP based
identity.

ok, that can be supported by the model without the = necessity to include the specific road warrior scenario.


BTW, Fernando = Pere=C3=B1iguez is helping with the review. Our plan is to add him as = author in the next version.


Paul

-----------------------------------------------------------
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=_CA24D225-DC26-48B0-902D-D3617FAEBDB6-- From nobody Tue Nov 27 14:38:50 2018 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 61121128CFD; Tue, 27 Nov 2018 14:38:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 b3wsegax7aYc; Tue, 27 Nov 2018 14:38:39 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 BF65612870E; Tue, 27 Nov 2018 14:38:38 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id t27so16403536wra.6; Tue, 27 Nov 2018 14:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XP/rThBQgYf10rO6R+vCfV29xXBl9OnULMSPZS9+PR8=; b=oSsTN0kB4LIZ+t6dJg2k4w7j5q1dxYxgDNHb50MB2vYIa5bYaL3UBAyFvOwFoUebsp DYPTZLk/muk6d0EF9KUfvSF4Ba3Kr7WTRqsx8j9LDt3MavsgTuhj56Zk0sRV9tagfMN+ 6qmkfsWDMrJQnZ+txleSCjuJpSxRjCUZ/Le+Z3iKKMu3WpSkvyhhOpla9gTQqzVV3cz8 BPccjNnlfoBugA4Tn5gHmobibbUWXH5L7fuZTM7p060eM8ld83NrV/8mtOn+LWXCmo6E bB/d7MBpd6oZK+qdNWxbKGabQRrTg31747IvZt1BZgEDFbmyyxlSvNKpn7DYnkDQ2s50 QVAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XP/rThBQgYf10rO6R+vCfV29xXBl9OnULMSPZS9+PR8=; b=dtGMbkyyhU5Iv4XzoNWKiYXHanWUS2M7IKRwatW2LVA6pypEEyonkcbEM9NKsUdgFD 8sudYgowuRPp60Iu8ZzCDTYXfWieTfCEjNj+P4rMvZUI/NnK75w1tOxNKyhXgPV9Se+o PoCE7H5omlJ4VPjzdP1bosOPOVekbVEaL+CZykLQrOSMWXEkRCK1JKyTSwLWDFnOxWrx Y+HrHVjup4GLRfQkhQzPuOTlMMEE6iFYMtbJObcwrPFWaBUy83wdcAmvKS1LFILu3eFm OoD/iV/UTOYdMjHWM7p9Jhx6xLZiNKvcZiU+kBbQUqtXYb3Bq0uEv5dBm4Em8eViVHTi /Gtw== X-Gm-Message-State: AA+aEWbXdjwws3pP9ccZqk/Wnf9Hd9gEE2mEqpe0PqiyIVRhO0TSyc1Q 6eMW/YPdWQ1LBceAoG+7MUM= X-Google-Smtp-Source: AFSGD/XGIc9kBrLTxXYIHr6tEFcTQDocw236ex0toXvpJ0YDX6LosaWd5WGUkD6SmpFfecOPM70tHg== X-Received: by 2002:a5d:6187:: with SMTP id j7mr29342294wru.300.1543358317194; Tue, 27 Nov 2018 14:38:37 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 142sm946144wmw.27.2018.11.27.14.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 14:38:36 -0800 (PST) From: Yoav Nir Message-Id: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_187B6ED1-2F73-4CB4-8DF9-ECAEDEEA7038" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 28 Nov 2018 00:38:33 +0200 In-Reply-To: Cc: Paul Wouters , i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez To: Gabriel Lopez References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 22:38:42 -0000 --Apple-Mail=_187B6ED1-2F73-4CB4-8DF9-ECAEDEEA7038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A couple of remarks (with no hats) If we=E2=80=99re bikeshedding the names, I think the difference is that = in one case the two NSFs generate traffic keys between themselves, and = in the other it is the controller that generates the keys for them. So = how about =E2=80=9Cdistributed keying=E2=80=9D vs =E2=80=9Ccentralized = keying=E2=80=9D, or perhaps =E2=80=9Cautomatic keying=E2=80=9D vs =E2=80=9C= SDN keying=E2=80=9D. Also, I have been asked by someone not on this list whether our work = covers the road warrior use case. I said it didn=E2=80=99t and wondered = why. So I got these points: Road warriors are numerous and not where the administrator can configure = them manually. Additionally, the configuration of what networks, gateways (NSFs), and = resources a road warrior may access (in IPsec terms, the SPD and PAD) = change often. Because of the above, some automatic method of configuring SPD and PAD = is needed. There is also the issue of multiple VPN gateways covering similar = domains, and VPN gateways being overloaded or down for maintenance, as = well as malfunctions in the network behind those VPN gateways. So the = decision on which gateway a road warrior should use to access a = particular resource is also a natural question to ask an SDN controller. Since I used to work for a VPN vendor, I can tell you what our product = did: The current configuration was formatted (automatically by a management = function) as a text file that the road warrior downloaded through the = VPN gateway (the gateway doubled as a server serving this one file) The proper gateway to connect to was determined by pinging all gateways = that were possible according to the configuration file. This did not account for any internal networking issues. I don=E2=80=99t know if this should be part of *this* effort, but there = is a use case for road warrior SDN. Yoav= --Apple-Mail=_187B6ED1-2F73-4CB4-8DF9-ECAEDEEA7038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = couple of remarks (with no hats)

If we=E2=80=99re bikeshedding the names, I think the = difference is that in one case the two NSFs generate traffic keys = between themselves, and in the other it is the controller that generates = the keys for them.  So how about =E2=80=9Cdistributed keying=E2=80=9D= vs =E2=80=9Ccentralized keying=E2=80=9D, or perhaps =E2=80=9Cautomatic = keying=E2=80=9D vs =E2=80=9CSDN keying=E2=80=9D.


Also, I have been asked by someone not on this list whether = our work covers the road warrior use case. I said it didn=E2=80=99t and = wondered why. So I got these points:
  • Road warriors are numerous and not = where the administrator can configure them manually.
  • Additionally, the configuration of what networks, gateways = (NSFs), and resources a road warrior may access (in IPsec terms, the SPD = and PAD) change often.
  • Because of the above, some = automatic method of configuring SPD and PAD is needed.
  • There is also the issue of multiple VPN gateways covering = similar domains, and VPN gateways being overloaded or down for = maintenance, as well as malfunctions in the network behind those VPN = gateways. So the decision on which gateway a road warrior should use to = access a particular resource is also a natural question to ask an SDN = controller.

Since I used to work for a VPN vendor, I can tell you what = our product did:
  • The current configuration was formatted (automatically by a = management function) as a text file that the road warrior downloaded = through the VPN gateway (the gateway doubled as a server serving this = one file)
  • The proper gateway to connect to was = determined by pinging all gateways that were possible according to the = configuration file.
  • This did not account for any = internal networking issues.

I don=E2=80=99t know if this = should be part of *this* effort, but there is a use case for road = warrior SDN.

Yoav
= --Apple-Mail=_187B6ED1-2F73-4CB4-8DF9-ECAEDEEA7038-- From nobody Wed Nov 28 03:06:32 2018 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 B01D3130F70; Wed, 28 Nov 2018 03:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 8KAWTTV8ZH8d; Wed, 28 Nov 2018 03:06:21 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05C130E27; Wed, 28 Nov 2018 03:06:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CD0E31FF97; Wed, 28 Nov 2018 12:06:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HBtQgBqbhkgw; Wed, 28 Nov 2018 12:06:18 +0100 (CET) Received: from [155.54.12.16] (unknown [155.54.12.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id C94581FE9E; Wed, 28 Nov 2018 12:06:16 +0100 (CET) From: Rafa Marin-Lopez Message-Id: <6036A6CE-A851-4FEB-AB05-6375CE4B1D66@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_49E2A981-B6FA-4649-AF43-E72A2AA0EEE3" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 28 Nov 2018 12:06:16 +0100 In-Reply-To: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> Cc: Rafa Marin-Lopez , Gabriel Lopez , Paul Wouters , i2nsf@ietf.org, "ipsec@ietf.org WG" To: Yoav Nir References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 11:06:24 -0000 --Apple-Mail=_49E2A981-B6FA-4649-AF43-E72A2AA0EEE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav: > El 27 nov 2018, a las 23:38, Yoav Nir escribi=C3=B3= : >=20 > A couple of remarks (with no hats) >=20 > If we=E2=80=99re bikeshedding the names, I think the difference is = that in one case the two NSFs generate traffic keys between themselves, = and in the other it is the controller that generates the keys for them. = So how about =E2=80=9Cdistributed keying=E2=80=9D vs =E2=80=9Ccentralized = keying=E2=80=9D, or perhaps =E2=80=9Cautomatic keying=E2=80=9D vs =E2=80=9C= SDN keying=E2=80=9D. The IKE case and IKE-less seems to show clearly both cases. It does not = mean your proposal does not but I guess I got used to IKE and IKEless = cases now :) apart from the fact the IKE-less reflects clearly that IKE = is not shipped in the NSF. >=20 >=20 > Also, I have been asked by someone not on this list whether our work = covers the road warrior use case. I said it didn=E2=80=99t and wondered = why. So I got these points: > Road warriors are numerous and not where the administrator can = configure them manually. > Additionally, the configuration of what networks, gateways (NSFs), and = resources a road warrior may access (in IPsec terms, the SPD and PAD) = change often. > Because of the above, some automatic method of configuring SPD and PAD = is needed. > There is also the issue of multiple VPN gateways covering similar = domains, and VPN gateways being overloaded or down for maintenance, as = well as malfunctions in the network behind those VPN gateways. So the = decision on which gateway a road warrior should use to access a = particular resource is also a natural question to ask an SDN controller. >=20 > Since I used to work for a VPN vendor, I can tell you what our product = did: > The current configuration was formatted (automatically by a management = function) as a text file that the road warrior downloaded through the = VPN gateway (the gateway doubled as a server serving this one file) > The proper gateway to connect to was determined by pinging all = gateways that were possible according to the configuration file. > This did not account for any internal networking issues. >=20 > I don=E2=80=99t know if this should be part of *this* effort, but = there is a use case for road warrior SDN. It can definitely part of this effort. In fact it was part of this = effort. Our earlier version of the I-D (before becoming a WG document) = has this case: = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-01#= page-18. At some point, and due to our discussions during the = presentations of our I-D we decided to get rid of this one and focus on = host-to-host and gw-to-gw. However we believe the person you talked to = and you are giving good reasons to recover it.=20 Having said that, I would like to comment something we noticed when we = thought about this case: In the real case with road-warrior configuration (let us know if we are = mistaken) the host would be out of the radar of the Security Controller = (let=E2=80=99s think, for example, a mobile phone or a laptop).=20 Therefore, with IKE case, the SC could install IKE configuration but no = specific to any particular host (which is fine). =20 The IKE-less case is more complicated in the sense that if the host = cannot be configured by the SC, the host will use IKE but the VPN = concentrator won=E2=80=99t have IKE. So the IKE negotiation would have = to happen between the host and the SC. If we analyze this and it is = posible, we could go for also IKE less.=20 If we consider a case where the host can be also configured by the SC, = then it is both IKE and IKE-less cases are plausible.=20 Most probably we should start to analyzing the simple (and perhaps more = realistic) case: road warrior with IKE case where the SC does not = configure the host.=20 Best Regards. >=20 > Yoav ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_49E2A981-B6FA-4649-AF43-E72A2AA0EEE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Yoav:
El 27 = nov 2018, a las 23:38, Yoav Nir <ynir.ietf@gmail.com> escribi=C3=B3:

A couple of remarks = (with no hats)

If = we=E2=80=99re bikeshedding the names, I think the difference is that in = one case the two NSFs generate traffic keys between themselves, and in = the other it is the controller that generates the keys for them. =  So how about =E2=80=9Cdistributed keying=E2=80=9D vs = =E2=80=9Ccentralized keying=E2=80=9D, or perhaps =E2=80=9Cautomatic = keying=E2=80=9D vs =E2=80=9CSDN = keying=E2=80=9D.

The IKE case and IKE-less seems to show clearly = both cases. It does not mean your proposal does not but I guess I got = used to IKE and IKEless cases now :) apart from the fact the IKE-less = reflects clearly that IKE is not shipped in the NSF.



Also, I have been asked = by someone not on this list whether our work covers the road warrior use = case. I said it didn=E2=80=99t and wondered why. So I got these = points:
  • Road= warriors are numerous and not where the administrator can configure = them manually.
  • Additionally, the configuration of = what networks, gateways (NSFs), and resources a road warrior may access = (in IPsec terms, the SPD and PAD) change often.
  • Because= of the above, some automatic method of configuring SPD and PAD is = needed.
  • There is also the issue of multiple VPN = gateways covering similar domains, and VPN gateways being overloaded or = down for maintenance, as well as malfunctions in the network behind = those VPN gateways. So the decision on which gateway a road warrior = should use to access a particular resource is also a natural question to = ask an SDN controller.

Since I used to work for a VPN = vendor, I can tell you what our product did:
  • The current configuration was = formatted (automatically by a management function) as a text file that = the road warrior downloaded through the VPN gateway (the gateway doubled = as a server serving this one file)
  • The proper gateway = to connect to was determined by pinging all gateways that were possible = according to the configuration file.
  • This did not = account for any internal networking issues.

I don=E2=80=99t know if this = should be part of *this* effort, but there is a use case for road = warrior SDN.

It can definitely part of this effort. In fact it = was part of this effort. Our earlier version of the I-D (before becoming = a WG document) has this case: https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-01#page-18. At some point, and due to our discussions during = the presentations of our I-D we decided to get rid of this one and focus = on host-to-host and gw-to-gw. However we believe the person you talked = to and you are giving good reasons to recover it. 

Having said that, I would like to comment = something we noticed when we thought about this case:

In the real case with road-warrior configuration = (let us know if we are mistaken) the host would be out of the radar of = the Security Controller (let=E2=80=99s think, for example, a mobile = phone or a laptop). 

Therefore, = with IKE case, the SC could install IKE configuration but no specific to = any particular host (which is fine).  

The IKE-less case is more complicated in the sense = that if the host cannot be configured by the SC, the host will use IKE = but the VPN concentrator won=E2=80=99t have IKE. So the IKE negotiation = would have to happen between the host and the SC. If we analyze this and = it is posible, we could go for also IKE less. 

If we consider a case where the host can be also = configured by the SC, then it is both IKE and IKE-less cases are = plausible. 

Most probably we = should start to analyzing the simple (and perhaps more realistic) case: = road warrior with IKE case where the SC does not configure the = host. 

Best = Regards.


Yoav

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_49E2A981-B6FA-4649-AF43-E72A2AA0EEE3-- From nobody Wed Nov 28 04:26:00 2018 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 15C7A130DCE; Wed, 28 Nov 2018 04:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 IP5TmRwg2rDM; Wed, 28 Nov 2018 04:25:58 -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 A405512D4EF; Wed, 28 Nov 2018 04:25:57 -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 wASCPfkR001079 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Nov 2018 14:25:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wASCPeNX004004; Wed, 28 Nov 2018 14:25:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23550.35140.688895.435296@fireball.acr.fi> Date: Wed, 28 Nov 2018 14:25:40 +0200 From: Tero Kivinen To: Paul Wouters Cc: Spencer Dawkins , ipsec@ietf.org, draft-ietf-ipsecme-split-dns@ietf.org, The IESG In-Reply-To: <6cf92ec6-0ffd-9864-0793-bbf30fb638ae@redhat.com> References: <154275031487.29795.6995020474049388117.idtracker@ietfa.amsl.com> <23545.49026.588213.633610@fireball.acr.fi> <6cf92ec6-0ffd-9864-0793-bbf30fb638ae@redhat.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 12:25:59 -0000 Paul Wouters writes: > I did not really want to do that. It would also require updating RFC=20= > 7296. So instead, I just pushed a change with: >=20 > -=A0=A0 assigned domains.=A0 DNS queries for other domains MUST be se= nt to the > -=A0=A0 regular DNS service of the client. > +=A0=A0 assigned domains.=A0 DNS queries for other domains SHOULD be = sent to > +=A0=A0 the regular DNS service of the client unless it prefers to us= e the > +=A0=A0 IPsec tunnel for all its DNS queries.=A0 For example, the cli= ent could > +=A0=A0 trust the IPsec provided DNS servers more than the locally pr= ovided > +=A0=A0 DNS servers especially in the case of connecting to unknown o= r > +=A0=A0 untrusted networks (eg coffee shops or hotel networks).=A0 Or= the > +=A0=A0 client could prefer the IPsec based DNS servers because those= provide > +=A0=A0 additional features over the local DNS servers. >=20 > > Anyways I think changing that to say "SHOULD be sent" could work > > better, i.e., depending on the policy clients could either send > > requests to normal DNS server or to the server provided in IKE. >=20 > Yes, done. see above. Looks good.=20 > > Note, that the original configuration payload was supposed to provi= de > > similar information than what DHCP does, so client does not need to= > > have anything preconfigured, but can get the whole network > > configuration from the server. This included addresses, dns servers= , > > etc, and even DHCP server address that it can use to get attributes= > > not included in the configuration payload. Usually the configuratio= n > > parameters received from configuration payload replaced the paramet= ers > > they had before. >=20 > Yes, but with split-tunnel, the client is clearly stepping in with on= e=20 > foot while keeping the other foot dry :) Agreed. My text was mostly to explain people not familiar with configuration payload what was the original meaning for them in non-split-tunnel context. --=20 kivinen@iki.fi From nobody Fri Nov 30 07:57:52 2018 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 EFBAA128BCC for ; Fri, 30 Nov 2018 07:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 BpN5jDpXpYR1 for ; Fri, 30 Nov 2018 07:57:48 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840122.outbound.protection.outlook.com [40.107.84.122]) (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 B459F127598 for ; Fri, 30 Nov 2018 07:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FBaybnYKXaxUDuosx9rYxpmYtF7eEVFiuSY+oZQk/No=; b=UbkpydNmr/uJDxQcMNuTdbONki2Qlz211rwqBEd4vT1DBq/BU2ap/T0qMKf0GVkHG8T0k57YThyEsWE+N8/CdzGwKpQIVUzzH90ibONmDySYCLka1eLk5ym4sAiQVZgW9bTCmLRRnv7eIu66m+viI2YXo5+DerBTsD7+wsTyxzU= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3261.namprd09.prod.outlook.com (20.177.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.19; Fri, 30 Nov 2018 15:57:47 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::942f:14c:4a48:16e4]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::942f:14c:4a48:16e4%2]) with mapi id 15.20.1361.019; Fri, 30 Nov 2018 15:57:46 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-qr-ikev2-04 Thread-Index: AdSIxTGFTPQKnwRhTNewgSDpaAoxRg== Date: Fri, 30 Nov 2018 15:57:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR09MB3261; 6:3gQP1bkr8H0eq3uDBavG42Rm+CIk1WsBZeNS5TlAvfxY6iET0kS+9FqL8NaIWulx/Pe23Yib/Xo3EeRl+CCvKHKOvHHtUK4rwniPyghUhl4Py06RNk1STRgx9aY7ERrtCvyENAI5bjKfqmO4oDw2PuMGTS/typYxqBQ/KeGlwdDGc678WmNmc1QivxnC6fsuqjFY/h96bx+3O14xfhDzD3t9iz9GJiluHmNyY+j/I15v80DwA9PIXu15QAfFDJ/J6efxa7fM6y2TjL9DRsg2VJGAYIklGmovPuqMSVE+3+jmN4ndoFLI5Bz3Wpf//iNSaQJ5a5EzCBWQECJnQXCPp5QbG3/7siTS4XnoTJQqN160TyJw3r3uj3W/aSm4bxxRXamM7CPeXNoLtELXwQHmrjcI6OT/gnRo1aYmeK2z8XV6ajRNZTZPYUUP7MRNAHYweQ8xcAuC46LIVl2RD8/TPw==; 5:KliO3DstfUX7F8zx0WESKbneI125KMRGrWaG2H7Qi5VcFiGE4oB38DfWbHc3Y/AFX49n3sqz1t7jFsd49m7HIWI5ij18GsGLKVm9yRTDf5YvDVpsWqgRgjYLUOzxMnglCsH9koRFU5DjMldETpBdusJ1RTR8mOXwZiqpPxVYfbk=; 7:W4pCrpujR/1yLakEdIJto99VCj8JqXqpkqkUkNqf9H4alw47o8nw70Ezlco5bsubpO5JvtYAZ/JRx4fOMGxwCxnFDjD7miL5aS80MFdsME47VxatiSEsDqCxJI9jSiH6ZOflvebkmu8zPhDco9cqpA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 877f079e-94ad-4a0f-65a9-08d656dc927a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR09MB3261; x-ms-traffictypediagnostic: SN6PR09MB3261: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231453)(999002)(944501410)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:SN6PR09MB3261; BCL:0; PCL:0; RULEID:; SRVR:SN6PR09MB3261; x-forefront-prvs: 087223B4DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(346002)(376002)(199004)(189003)(8936002)(25786009)(316002)(71190400001)(2906002)(71200400001)(14454004)(486006)(6436002)(102836004)(81156014)(81166006)(53936002)(8676002)(7736002)(305945005)(256004)(74316002)(6306002)(86362001)(476003)(6916009)(55016002)(9686003)(7696005)(6116002)(33656002)(186003)(99286004)(97736004)(3846002)(478600001)(105586002)(106356001)(6506007)(66066001)(26005)(68736007)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3261; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: Nm3EMargLLCkfFVWjEoLMT27a/UzcmV//CnsmSKtisAb+VMVpfJsRmJbRxy9mF9mwRQSbDj4xRHbhiAqbMbYTh44dkyODl5SJvAC8vf3Yk1HV8gFUxGObsJGdx+DumMC3KuQZ5K3p7NHJGMRa8fOkZ/Iv/kWwhAFijvmQhn7ntkl0nKqRav5/NDB2CjsWg3MMnj9TtZFFgY221GB5/QrQ75qbVmugnUi2/S7hboaOJIOqgr9puaPQPCP3GWyVYwmRzT9vAqY+GVKlzQqJsY7i79vNtjqDRQOK8U1PF4lWXl/jCV6ZT6j4bzcNDKah/LFlKBW9U2tPwNWdMsCc3QV2iGh/r3TqFtkzb6JOM+YiCE= spamdiagnosticoutput: 1:99 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-Network-Message-Id: 877f079e-94ad-4a0f-65a9-08d656dc927a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 15:57:46.8081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3261 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 15:57:51 -0000 This message starts a working group last call (WGLC) on draft-ietf-ipsecme-= qr-ikev2-04, which will conclude on December 14, 2018 at UTC 23:59. Please = review and provide feedback on the -04 version (https://datatracker.ietf.or= g/doc/draft-ietf-ipsecme-qr-ikev2/). Please indicate if you believe this dr= aft is ready for publication or if you have comments that must be addressed= before the draft progresses to the IESG. Regards, Dave and Tero