From nobody Mon Nov 5 06:28:22 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E0128BCC for ; Mon, 5 Nov 2018 06:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dTUZBVfM; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kIzfbn3L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH1btp0I0377 for ; Mon, 5 Nov 2018 06:28:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D87941277BB for ; Mon, 5 Nov 2018 06:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541428098; x=1544020098; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FTcbEyIcRMeuwrlJUCNKiQb/R2JuMENhPB6MR6k8G3g=; b=dTUZBVfMRnH28DZBVLDHa1XtZgh2gPdgBepGwrwevYTHmOFj3e95o+ftNpt+tMgM /Y6GZM/TspRUdRTu0T9Xkxod9M4s//W5kQMprYhBoT092AG9Gz6znBQZHCVXG+xS s4oeO5ApmLCefVAAwUfH2OtRwaXy61Kl5X1rTr4xIlY=; X-AuditID: c1b4fb30-671b09e000007d19-31-5be05382d629 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.FF.32025.28350EB5; Mon, 5 Nov 2018 15:28:18 +0100 (CET) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESSMB503.ericsson.se (153.88.183.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 15:28:17 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 15:28:17 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 5 Nov 2018 15:28:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FTcbEyIcRMeuwrlJUCNKiQb/R2JuMENhPB6MR6k8G3g=; b=kIzfbn3Lfddxe2wrmTnuOMmQWcSw/uInxFeV9mGG47NImZQOl8dHDxhafW0+RaScycaUq40eAeWx4SomULRh82Z5YrgPf+gN4z8Uc2AsB8JRz7TSQszskbDJAgh7U9A3UuNzCPclHeOD45RwUNPpzQEZPgQEW6zUEKzCdkynKto= Received: from AM6PR07MB4728.eurprd07.prod.outlook.com (20.177.38.92) by AM6PR07MB4614.eurprd07.prod.outlook.com (20.177.38.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.10; Mon, 5 Nov 2018 14:28:17 +0000 Received: from AM6PR07MB4728.eurprd07.prod.outlook.com ([fe80::645d:55b6:824c:b390]) by AM6PR07MB4728.eurprd07.prod.outlook.com ([fe80::645d:55b6:824c:b390%2]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 14:28:17 +0000 From: Miika Komu To: hip WG Thread-Topic: IESG review of NAT traversal draft and encrypted parameters Thread-Index: AQHUdRPKVFbj2E0doUehU8k1DBLn/w== Date: Mon, 5 Nov 2018 14:28:16 +0000 Message-ID: <677e527a-bf01-3473-7f49-ff92b428e603@ericsson.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6PR06CA0017.eurprd06.prod.outlook.com (2603:10a6:20b:14::30) To AM6PR07MB4728.eurprd07.prod.outlook.com (2603:10a6:20b:19::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB4614; 6:FnSZiKu4T8PG2JXVy9HOeh17V+omT5SNpvPyg+llnfZFKALiW/V82yNOycAVSZuke/3ANGzjQMOoV3kuUAfQBVm/lObMh0fj5cW/uiNN9FqtcsA835ETbLH9jBX2UHxjr7WHmFVMWVhFKxhKFl8hxUF/hpF+hKitNHNl4g0W8Vj9Ty/LOF0x02hsT+snCHoO5bvphchOYpGKEp3c48bgQEDRy3vorQmQ08UB3AMFLK/5Lrm8VazVBAjBROSDfZsnZJdm+SJnY6wFqq/nXbVtkHO+5tJiNO8odmKxdSfxRmAoXgyiPEda+jcoIlVwb7KjsjH2iGX9DWnzbgRzhYl1sdOR4v+tPWyiVT55x23fnYRoaYmI0XYKs8rjaJjAuPCMO7EAU0g4YlPNy6CWoguVf3wUmw3Ah1l5bLVvvOq8TcvpPUygPfMqlvtLyFz1CyYsKKZsBSQ5nw6uWsFYfan3tg==; 5:qIR3lLbDEaKFs2sU5MKMHKLITAnvjKOKZmznBlZmGeGK1l771e54yPY4e+WjwMOIgAGEUF4pOi/3pfvtuJIxFvvV4OESuORmUQS3nhJUznLIpvNzuvCvM9/SdGpu1llJCZvvyy5ZI6i8EJwGzzdCdt8MRGbjw9j8z+fZSG44aw4=; 7:HIYHraB9X8Sjx5+thyd+WfwAILYkEJUgYOarJOHh6XWCdYF8dEEgXumoQzyIjpPN/Tp+MeuHDhZmCiHt1Km8QVcfzVM01Zgz0I2Fx0eNQI2dCeuHr0J0f+YjPAmy84MZZPsdCJzCiClGjOXtDGnFrQ== x-ms-office365-filtering-correlation-id: 9c770e26-cb28-4235-19b7-08d6432aec72 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB4614; x-ms-traffictypediagnostic: AM6PR07MB4614: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB4614; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4614; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(366004)(346002)(376002)(199004)(189003)(36756003)(105586002)(8936002)(6916009)(3846002)(5660300001)(6116002)(53936002)(68736007)(52116002)(31686004)(25786009)(102836004)(2616005)(81156014)(476003)(2906002)(14454004)(97736004)(478600001)(26005)(256004)(8676002)(305945005)(2900100001)(86362001)(99286004)(7736002)(81166006)(6436002)(31696002)(316002)(486006)(106356001)(386003)(66066001)(186003)(71190400001)(6486002)(71200400001)(6512007)(6506007)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4614; H:AM6PR07MB4728.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: itlzvmECEk7haf7PhDQY1jEwSplAhEDPaJnKOc28ox0tle0yMwqc9kiOzAW6IvmTl8hBzJ6kkKpfqUiphTi+FbmSBBcJIVi53buZ8d6quD9wzNz2LsRVpd6gR6UNQpg5D2n01YnEtbvUPTRqVgdTt12VcGnssiuLY4NpVz6iCD2yeLFushAC5SILaLO+sKjMLphLtJJSgOZbhcTwipQQc4S5qtTdhTIVG1ezi9jHT2ZbbxJW9EbcOzoMoVnbhuQw6MPEQ7k+9JaFwd0mZWdsiFMLERSqWKxy1WY3fnMJ3gpthbmYweZdu6+2OgZfdt1lWT3iqzsgsBOb9TQ8s+3ABlhzeRA60ABaL5vPk68Y9cU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9c770e26-cb28-4235-19b7-08d6432aec72 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 14:28:16.9943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4614 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42KZGbG9Urcp+EG0wYmlPBZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvLGecwFrzgrfq8paWA8wdnFyMkhIWAiMXn3UbYuRi4OIYEj jBJvG/ezQDhfGSVm7H7HCOcc37YJqmwxk8SLDQ+ZQfpZBCYwS0w+kwmRmMgk0f3kBhOE85BR Yu+xrUwgVWwCWhKr7lwH6xARkJHYsOkFK4gtLOAi8eBmHxNE3FNi26eLUDV6Eht7GlkgNqhI rDjxnB3E5hWwl2jrWAtWzyggK7Fy8z+wemYBcYlbT+YzQXwkILFkz3lmCFtU4uXjf6wgB0kI TGeUmLf1HitEc5RE96t+FogiHYmz158wQtiKEmffPYQaJCtxaX43I0TzNTaJtsbZUA2+Ei/X PWSCSBxnlPj9eBdUt5bEvKvLWSHsbIlbe09Dxa0kfixZwA5hy0ms6n3IAtXMLPGurZ91AqPh LCRvzGLkALI1Jdbv0ocIe0hcXrSXGcJWlJjS/ZB9Fjg0BCVOznzCsoCRdRWjaHFqcVJuupGR XmpRZnJxcX6eXl5qySZGYAI5uOW3wQ7Gl88dDzEKcDAq8fBqOj6IFmJNLCuuzD3EKMHBrCTC q8QGFOJNSaysSi3Kjy8qzUktPsQozcGiJM5r4bc5SkggPbEkNTs1tSC1CCbLxMEp1cDIGBhp LW6c8XmGE98hps+OuUF/nM75S+7tW1qwft9Nq+LYaH1LvkcikkdXtXvMTOhY4yC3/KT0lB0/ 7xtLMnSvmPIw3THZfccpTtGkr8GvmE48bAo+Pzuq+nb+lSS2Y5/qi77xC5TL+AWZ/TnPE/ye ffYW36UK8dV+houU5/jkX1HNmDGvnEuJpTgj0VCLuag4EQAPK3yxHAMAAA== Archived-At: Subject: [Hipsec] IESG review of NAT traversal draft and encrypted parameters X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 14:28:22 -0000 SGkgZm9sa3MsDQoNCkkgYW0gZmluYWxseSB0cnlpbmcgc2NyYXRjaCBzb21lIHRpbWUgdG8gYWRk cmVzcyBJRVNHIGZlZWRiYWNrIHJlbGF0ZWQgDQp0byBOQVQgdHJhdmVyc2FsIGRyYWZ0LiBFcmlj IFJlc2NvcmxhIChhbW9uZyBvdGhlcnMpIHF1ZXN0aW9uZWQgd2h5IHdlIA0KaGF2ZSBjaG9zZW4g dG8gaGF2ZSB0aGUgbG9jYXRvcnMgKGFrYSBjYW5kaWRhdGVzKSBpbiBwbGFpbnRleHQgd2hlcmVh cyANCmluIElDRSwgdGhlIGxvY2F0b3JzIGFyZSBYT1JyZWQgdG8gcHJvdGVjdCBhZ2FpbnN0IG1p ZGRsZWJveCB0YW1wZXJpbmcuIA0KVGhlIG9yaWdpbmFsIHJlYXNvbmluZyBmb3IgdGhpcyBpcyB3 YXMgdGhhdCBiZWNhdXNlIHRoYXQgaXMgdGhlIHdheSANCm5vbi1OQVQgdHJhdmVyc2FsIHZlcnNp b24gb2YgdGhlIEhJUCB3b3JrcyAoUkZDNzQwMSkuDQoNCkkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBY T1JyaW5nIHdpdGggSElQIGJlY2F1c2Ugd2UgaGF2ZSBtb3JlIHBvd2VyZnVsIA0KbWVjaGFuaXNt cyBpbiBISVAuIFNvLCBJIGFtIGdvaW5nIHRvIGFkZCBzb21lIHRleHQgdGhhdCBtYW5kYXRlcyB0 aGF0IA0KdGhlIExPQ0FUT1IgcGFyYW1ldGVyIG11c3QgYmUgZW5jYXBzdWxhdGVkIGluc2lkZSBF TkNSWVBURUQgcGFyYW1ldGVyIA0Kd2hlbiBJQ0UtSElQLVVEUCB3aWxsIGJlIHVzZWQuIFRoZSB0 cmFkZW9mZiBoZXJlIGlzIHRoYXQgd2UgZmF2b3IgDQplbmQtaG9zdCBwcml2YWN5IGF0IHRoZSBj b3N0IG1pZGRsZWJveCB0cmFuc3BhcmVuY3kuDQoNClBsZWFzZSBsZXQgbWUga25vdyBkdXJpbmcg dGhlIHR3byBuZXh0IHdlZWtzIGlmIHlvdSBkaXNhZ3JlZSwgb3RoZXJ3aXNlIA0KSSBjb25zaWRl ciB0aGUgaXNzdWUgdG8gYmUgcmVzb2x2ZWQgYXQgbGVhc3QgZnJvbSB0aGUgV0cgcGVyc3BlY3Rp dmUuDQo= From nobody Wed Nov 7 13:37:24 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE49124BE5 for ; Wed, 7 Nov 2018 13:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 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_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MgNua2Gu; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PfpK6G6+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZFb_hfTfDNU for ; Wed, 7 Nov 2018 13:37:21 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 08E4112F1AB for ; Wed, 7 Nov 2018 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541626636; x=1544218636; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wumOS5FxLaLOHoRqDnCwVPyoXMBCJKnGfjzxwLmh/LQ=; b=MgNua2GuxOVswp4eFwCDh+pHcMaioMpm6GUMtlpS6lK2e1aOjcKMeyuyOtlO74yc kFGTmOPRXluQjOxus6buVJJx0aPwNt/oWpyrVyfp7Rt7ZeI+QK4e+F/ot5o8BmJr JSh+/nypNSN7FwzVTexIILdBB6gQ9USmILrVsw+qIpk=; X-AuditID: c1b4fb3a-45fff70000002747-e4-5be35b0c7c23 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E6.EE.10055.C0B53EB5; Wed, 7 Nov 2018 22:37:16 +0100 (CET) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESBMB502.ericsson.se (153.88.183.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 22:37:16 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 22:37:16 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 7 Nov 2018 22:37:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wumOS5FxLaLOHoRqDnCwVPyoXMBCJKnGfjzxwLmh/LQ=; b=PfpK6G6+lObzJC/Q3KQ4b1Pv2W757SSuy5aOg94Xo+OSQ1KKWaJijhbzimkWhRPUKO48iztdiDZFQoRF7xHoFo5H9E1daqAQcwjg/iDPngRWepxxqRUhRVdjrxs4sKUvza5YqrakuygWwFpyh3DDkZVv34XDVQvKPbD4mLV1c6w= Received: from AM6PR07MB4865.eurprd07.prod.outlook.com (20.177.118.22) by AM6PR07MB4677.eurprd07.prod.outlook.com (20.177.39.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Wed, 7 Nov 2018 21:37:14 +0000 Received: from AM6PR07MB4865.eurprd07.prod.outlook.com ([fe80::f0ee:62a8:97ea:5279]) by AM6PR07MB4865.eurprd07.prod.outlook.com ([fe80::f0ee:62a8:97ea:5279%3]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 21:37:14 +0000 From: Miika Komu To: Eric Rescorla , The IESG CC: "hipsec@ietf.org" , Gonzalo Camarillo , "hip-chairs@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" Thread-Topic: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT) Thread-Index: AQHT497tUmBXmn8MOU+Q++wdbIVom6VF/FUA Date: Wed, 7 Nov 2018 21:37:14 +0000 Message-ID: References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> In-Reply-To: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6PR0202CA0044.eurprd02.prod.outlook.com (2603:10a6:20b:3a::21) To AM6PR07MB4865.eurprd07.prod.outlook.com (2603:10a6:20b:59::22) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR07MB4677; 6:jNHFgRHeO4Fdx5Wk0dbz4He7X9R76e/1CuCbHyozx7C6A4SjR1ldBeaJyX1sfkNb/7XkCBr4CkDoOZAv6EfRvISoYnz/J4AM+quKAim4EOZtcbH/dSvmYW5+14kB9NfjuFRjM9sLOXssLUMwy6oUavqhQ+KG0EbqjuPP9e1Xfy7GdHZnTRrqUG6aWxH890J6Eg1KDHgU+jBqBKhn1EDSNvH5ozlx+mXc+6ZIHeAlGT/k78CJLCNaDTdTe+bqD+ydL5QaJUCFhiLy+S1Glv5NsJZm3ma3uZObb4yMdw1QpYtGz7nwurf4kEyT/278diGa68HBFfnjJ9y//3PIX8v+16kMUaA7d5RIeAuReE/7kuoAv9+JR37lkuk3W4JU1L4cHPqO7JcH64ciFpfJLfaAC7VxagTpwvaGiwNp0zYs9t+ovl2AEz+rMgmorghIh/UOte7xvk7yo3JLA1CYg7gFvg==; 5:cCJQbfwayOG7IgMCXJfXed83J0u0aCC7NN88VJJCbwpsRSsTRe3VyUG6Q+ENuDwQi93EDb4vg3ErSR2k5jelh9Y6Bdg5qJ68klP37DVUmnZ2vizmR0AGdVt1Mxk9UjW8xMkpYQtbesldAn64u/ImiXQuL+yrsHGOrBfJFvSdi3s=; 7:bo2ozCiMZULObfDzrWfRdYsGMK8haVscCZMMFoIl+ZDsV+4HhagxWM42vVCRAzB/nJc6Ot7H2SoJ52suiT5gNXHpNLlMbLKVrTCk5ebHKiqbt+BEQoSwAbcvVa7XYMNtP0jPfCPe5SdjZHR776xlAQ== x-ms-office365-filtering-correlation-id: 9735ca4f-221b-4cca-0446-08d644f92e8c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB4677; x-ms-traffictypediagnostic: AM6PR07MB4677: authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(158342451672863)(35073007944872); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231382)(944501410)(52105095)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB4677; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4677; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(136003)(366004)(396003)(51234002)(189003)(199004)(6436002)(3846002)(52116002)(36756003)(44832011)(99286004)(316002)(11346002)(4326008)(2616005)(81166006)(476003)(81156014)(54906003)(8936002)(68736007)(6246003)(14454004)(25786009)(6506007)(186003)(66066001)(386003)(6116002)(8676002)(102836004)(2900100001)(305945005)(106356001)(6486002)(966005)(7736002)(229853002)(31686004)(256004)(14444005)(53546011)(86362001)(71190400001)(71200400001)(2906002)(478600001)(105586002)(97736004)(486006)(446003)(76176011)(5660300001)(110136005)(53936002)(6306002)(31696002)(26005)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4677; H:AM6PR07MB4865.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2yqrikzSYGXMTHXV22V6jKEXsMjBA0OPUtPSHCBJrjK93ywBN03HtzbrOhEi62udKqU6VqzZR+ZGXzqszTG0FTWpuAXIylGrYra09j9rr8uN/rc94F+Ae+xLXFDaUkyKQ/zeNkVG5Fa6ds62/Uu1KxU1qvRQ3oKlT8iXZWw+JAW19k9fhDwXmr4DDwCFCrg58mQSItk10YvrlkZ2QNzwhl7K2zyNfz61wHkkoaaSvHT8e6aO3lBkFpJ8TiemJUI4LOjQSFcZSD7KwMe/NVhJxJJ2slAe+Ejl+Vdib5dVFiJpkSGfAvHEoO4fL5K8YWVTvw4LWgFZGU0wUKqoyifX4JW7KkpQXQzLX6Le5k3CfJI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9735ca4f-221b-4cca-0446-08d644f92e8c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 21:37:14.2490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4677 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGObt323W5Oi7FF3NQKwTFdIrBsuj7j1VqZn+ULsiVNxXnB7sm WlFKlGNmanPaNNDULM2hWJGahS5JzNSy0krBdOZnBokjZTpyuxb993vO8z7nPC8cihBVcD2o +KRUWp2kVEl4AtJw6hmz3VlhVkjfznvKsus0hOzhbC9f1nFdy5fpK3SE7M5yAbGPK6+qWuLI deYbRDgnSrA7hlbFp9Fq/z3Rgjj9i0p+ynJaenl1JpmJFhgtcqIAB8FMyXO+FgkoEe5AYOnK 5bHCguDN/CL5T7QUWpA9IsKVHOjOl9oNEucToHlqXMsXcMCm/0SwYhTBSGkz3x7hYR+oHR4k 7OyKg2HGOuC4l8BzCDqbNRy7sRGroLvpJ8kOJcLd4uo1DoTvQ0ZHmMTboM4yxbOzEO+Fut5W ku0UBqPNRVw7O+FjMGGedHRFWAw1j22OLIHd4et4GYddG0NVax/BshtMm21ceyHABgTDWTrE Gr7QMzi+xpthWG/ksyyG/rIcxAYGeKD7tsRljVBYnLrPY41OBMulY2vP+UB/dgPBVoqCnJk8 kj1PgMoJIz8fBZX817AEUavsDfUt/izK4WZPNDuxBQpzRvkljv1doMswTpYjbi1yY2iGSYwN DPSj1fHnGCY5yS+JTm1Eqz+n/Yk1uAm1T+43IUwhibNwR4RZIeIq05iMRBMCipC4CnMfjSlE whhlxkVanXxGfUFFMya0iSIl7sID52VRIhyrTKUTaDqFVv91OZSTRyY6JFw3PPuyLSsk7oi8 TRz+KqRivVe174/oMPJS1lbN0OGuiKuCW+3veWGf1d6G2ZPHsyJbr5ikfbaivIaZmo6hDJcC aWUsfXBlV+vr9BC3ucsrX3q03VbFh8jT9Ud/WX9fo9/VBX0MkO/08rVFPjjhOS0uPtt4O3Rh +t7ABhdjsPeIhGTilAE+hJpR/gE0LdseNQMAAA== Archived-At: Subject: Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 21:37:23 -0000 SGkgRXJpYywNCg0KYXBvbG9naWVzIGZvciB0aGUgYmVsYXRlZCByZXNwb25zZSwgSSBhbSBub3Qg d29ya2luZyBvbiBISVAgYW55bW9yZSwgc28gDQppdCBoYXMgYmVlbiByYXRoZXIgZGlmZmljdWx0 IHRvIGZpbmQgdGltZSBmb3IgdGhpcy4NCg0KT24gNS80LzE4IDIyOjM0LCBFcmljIFJlc2Nvcmxh IHdyb3RlOg0KPiBFcmljIFJlc2NvcmxhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWhpcC1uYXRpdmUtbmF0LXRyYXZlcnNhbC0yODog RGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtaGlwLW5hdGl2ZS1uYXQtdHJhdmVyc2FsLw0KPiANCj4gDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFJpY2gg dmVyc2lvbiBvZiB0aGlzIHJldmlldyBhdDoNCj4gaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3Zj ZGV2Lm1vemF3cy5uZXQvRDMwOTkNCj4gDQo+IA0KPiBJIGFtIHZlcnkgZmFtaWxpYXIgd2l0aCBJ Q0UgYW5kIHlldCBJIGZvdW5kIHRoaXMgZG9jdW1lbnQgZXh0cmVtZWx5DQo+IGhhcmQgdG8gZm9s bG93LiBUaGUgcHJvYmxlbSBpcyB0aGF0IGl0IGNoZXJyeS1waWNrcyBwaWVjZXMgb2YgSUNFIGFu ZA0KPiBJJ20ganVzdCBub3Qgc3VyZSB0aGF0IGl0J3MgYSBjb21wbGV0ZSBzcGVjaWZpY2F0aW9u IHdoZW4gcHV0IGFsbA0KPiB0b2dldGhlci4gSSBoYXZlIG5vdGVkIGEgbnVtYmVyIG9mIHBsYWNl cyB3aGVyZSBJIGFjdHVhbGx5IGFtIG5vdCBzdXJlDQo+IGhvdyB0byBpbXBsZW1lbnQgc29tZXRo aW5nLCBhbmQgZml4aW5nIHRob3NlIHdpbGwgcmVzb2x2ZSB0aGlzDQo+IERJU0NVU1MsIGJ1dCBJ TU8geW91IHJlYWxseSBzaG91bGQgdG90YWxseSByZXdyaXRlIHRoaXMgZG9jdW1lbnQNCj4gZWl0 aGVyIChhKSBhcyBhIHZhcmlhbnQgb2YgSUNFIG9yIChiKSBhcyBhbiBlbnRpcmVseSBuZXcgZG9j dW1lbnQgbm90DQo+IHdpdGggYSBwaWxlIG9mIG5ldyB0ZXh0IGFuZCB0aGVuIHJlZmVyZW5jZXMg b3V0IHRvIElDRSBzZWN0aW9ucy4NCg0KdGhlIGV4cGVjdGVkIHJlY2VpdmVycyBvZiB0aGUgd29y ayBhcmUgdGhlIGltcGxlbWVudGVycyBvZiBSRkM1NzcwLCBzbyANCnRoZSBkcmFmdCBmb2xsb3dz IHRoZSBzZWN0aW9uaW5nIG9mIHRoZSBSRkM1NzcwICh3aGljaCBoYXMgdHdvIA0KaW50ZXJvcGVy YWJsZSBpbXBsZW1lbnRhdGlvbnMpLg0KDQpJZiBJIHVuZGVyc3Rvb2QgeW91ciBjb21tZW50IHJp Z2h0LCB0aGUgdmFyaWFudCBvZiBJQ0UgKGEpIHdvdWxkIGZvbGxvdyANCnRoZSBJQ0UgZG9jdW1l bnQgc3RydWN0dXJlIGJ1dCB0aGVuIHRoZSBkb2N1bWVudCB3b3VsZCBub3Qgc2VydmUgYW55bW9y ZSANCkhJUCBpbXBsZW1lbnRlcnMgc28gd2VsbC4gV2hhdCBjb21lcyB0byBvcHRpb24gKGIpLCBJ IHRoaW5rIGl0IHdvdWxkIA0KbWFrZSB0aGUgdGhlIGRvY3VtZW50IHF1aXRlIGxvbmcgaWYgd2Ug cmVwbGljYXRlZCBldmVyeXRoaW5nIGluIHRoZSBJQ0UgDQpzcGVjaWZpY2F0aW9uIChhbmQgcG9z c2libHkgZnJvbSB0aGUgSElQIHNwZWNpZmljYXRpb25zKSBpbiB0aGUgZHJhZnQuDQoNCj4gREVU QUlMDQo+IFMgNC4yLg0KPj4gICAgICAgcmVxdWVzdCB0eXBlIFNIT1VMRCBOT1QgY3JlYXRlIGFu eSBzdGF0ZSBhdCB0aGUgQ29udHJvbCBSZWxheSBTZXJ2ZXIuDQo+PiAgICANCj4+ICAgICAgIElD RSBndWlkZWxpbmVzIFtJLUQuaWV0Zi1pY2UtcmZjNTI0NWJpc10gZm9yIGNhbmRpZGF0ZSBnYXRo ZXJpbmcgYXJlDQo+PiAgICAgICBmb2xsb3dlZCBoZXJlLiAgQSBudW1iZXIgb2YgaG9zdCBjYW5k aWRhdGVzIChsb29wYmFjaywgYW55Y2FzdCBhbmQNCj4+ICAgICAgIG90aGVycykgc2hvdWxkIGJl IGV4Y2x1ZGVkIGFzIGRlc2NyaWJlZCBpbiB0aGUgSUNFIHNwZWNpZmljYXRpb24NCj4+ICAgICAg IFtJLUQuaWV0Zi1pY2UtcmZjNTI0NWJpc10uICBSZWxheWVkIGNhbmRpZGF0ZXMgU0hPVUxEIGJl IGdhdGhlcmVkIGluDQo+IA0KPiBJZiB5b3UncmUgZ29pbmcgdG8gbm9ybWF0aXZlbHkgY2hlcnJ5 LXBpY2sgSUNFLCB5b3UgbmVlZCB0byBub3RlDQo+IHNwZWNpZmljIHNlY3Rpb25zLCBJIHRoaW5r Lg0KDQoNCmdvb2QgY2F0Y2gsIG5vdyB0aGF0IHRoZSBJQ0Ugc3BlY2lmaWNhdGlvbiBpcyBmaW5h bGx5IGFuIFJGQywgd2UgY2FuIGFkZCANCmEgcmVmZXJlbmNlIGhlcmUgYW5kIHRvIGEgbnVtYmVy IG9mIG90aGVyIHBsYWNlcyAod2hpY2ggSSBoYWQgY29tbWVudGVkIA0Kb3V0IGJlY2F1c2UgdGhl IHNlY3Rpb24gbnVtYmVyaW5nIGluIElDRSB3YXMgY2hhbmdpbmcpLg0KDQo+IFMgNC42LjIuDQo+ PiAgICANCj4+ICAgICAgIEEgaG9zdCBtYXkgcmVjZWl2ZSBhIGNvbm5lY3Rpdml0eSBjaGVjayBi ZWZvcmUgaXQgaGFzIHJlY2VpdmVkIHRoZQ0KPj4gICAgICAgY2FuZGlkYXRlcyBmcm9tIGl0cyBw ZWVyLiAgSW4gc3VjaCBhIGNhc2UsIHRoZSBob3N0IE1VU1QgaW1tZWRpYXRlbHkNCj4+ICAgICAg IGdlbmVyYXRlIGEgcmVzcG9uc2UsIGFuZCB0aGVuIGNvbnRpbnVlIHdhaXRpbmcgZm9yIHRoZSBj YW5kaWRhdGVzLiAgQQ0KPj4gICAgICAgaG9zdCBNVVNUIE5PVCBzZWxlY3QgYSBjYW5kaWRhdGUg cGFpciB1bnRpbCBpdCBoYXMgdmVyaWZpZWQgdGhlIHBhaXINCj4+ICAgICAgIHVzaW5nIGEgY29u bmVjdGl2aXR5IGNoZWNrIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjYuMS4NCj4gDQo+IEFyZSB5 b3Ugc3VwcG9zZWQgdG8gcHV0IHRoaXMgb24gYSBUT0RPIGNoZWNrIGxpc3QgYXMgd2l0aCBJQ0U/ DQoNCkkgYmVsaWV2ZSB5b3UgcmVmZXIgdG8gdGhlIHRyaWdnZXJlZC1jaGVjayBxdWV1ZToNCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0NDUjc2VjdGlvbi02LjEuNC4xDQoNCkkg Y2hhbmdlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQpBIGhvc3QgbWF5IHJlY2VpdmUgYSBjb25u ZWN0aXZpdHkgY2hlY2sgYmVmb3JlIGl0IGhhcw0KDQpyZWNlaXZlZCB0aGUgY2FuZGlkYXRlcyBm cm9tIGl0cyBwZWVyLiBJbiBzdWNoIGEgY2FzZSwgdGhlDQoNCmhvc3QgTVVTVCBpbW1lZGlhdGVs eSBnZW5lcmF0ZSBhIHJlc3BvbnNlIGJ5IHBsYWNpbmcgaXQgaW4gdGhlIA0KdHJpZ2dlcmVkLWNo ZWNrIHF1ZXVlLCBhbmQgdGhlbiBjb250aW51ZQ0Kd2FpdGluZyBmb3IgdGhlIGNhbmRpZGF0ZXMu DQoNCj4gUyA1LjguDQo+PiAgICANCj4+ICAgIDUuOC4gIFJFTEFZX0hNQUMgUGFyYW1ldGVyDQo+ PiAgICANCj4+ICAgICAgIEFzIHNwZWNpZmllZCBpbiBMZWdhY3kgSUNFLUhJUCBbUkZDNTc3MF0s IHRoZSBSRUxBWV9ITUFDIHBhcmFtZXRlcg0KPj4gICAgICAgdmFsdWUgaGFzIHRoZSBUTFYgdHlw ZSA2NTUyMC4gIEl0IGhhcyB0aGUgc2FtZSBzZW1hbnRpY3MgYXMgUlZTX0hNQUMNCj4+ICAgICAg IFtSRkM4MDA0XS4NCj4gDQo+IFdoYXQga2V5IGlzIHVzZWQgZm9yIHRoZSBITUFDPw0KDQpjbGFy aWZpZWQgdGhpcyBhcyBmb2xsb3dzOg0KDQpbLi5dIEl0IGhhcyB0aGUgc2FtZSBzZW1hbnRpY3Mg YXMgUlZTX0hNQUMgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNC4yLjEgDQppbiBbUkZDODAwNF0u ICBTaW1pbGFybHkgYXMgd2l0aCBSVlNfSE1BQywgYWxzbyBSRUxBWV9ITUFDIGlzIGlzIGtleWVk IA0Kd2l0aCB0aGUgSElQIGludGVncml0eSBrZXkgKEhJUC1sZyBvciBISVAtZ2wgYXMgc3BlY2lm aWVkIGluIHNlY3Rpb24gNi41IA0KaW4gW1JGQzc0MDFdKSwgZXN0YWJsaXNoZWQgZHVyaW5nIHRo ZSByZWxheSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGFzIA0KZGVzY3JpYmVkIGluIFNlY3Rpb24g NC4xLg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cj4gUyAyLg0KPj4gICAgICAgU2VydmVyIHJlZmxleGl2ZSBjYW5kaWRhdGU6DQo+PiAgICAgICAg ICBBIHRyYW5zbGF0ZWQgdHJhbnNwb3J0IGFkZHJlc3Mgb2YgYSBob3N0IGFzIG9ic2VydmVkIGJ5 IGEgQ29udHJvbA0KPj4gICAgICAgICAgb3IgRGF0YSBSZWxheSBTZXJ2ZXIuDQo+PiAgICANCj4+ ICAgICAgIFBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZToNCj4+ICAgICAgICAgIEEgdHJhbnNsYXRl ZCB0cmFuc3BvcnQgYWRkcmVzcyBvZiBhIGhvc3QgYXMgb2JzZXJ2ZWQgYnkgaXRzIHBlZXIuDQo+ IA0KPiBZb3Ugc2hvdWxkIGluZGljYXRlIHdoaWNoIGRlZmluaXRpb25zIGFyZSB0aGUgc2FtZSBh cyBJQ0UvU1RVTg0KDQp0aGVzZSBib3RoIGFyZSB0aGUgc2FtZSBhcyBpbiBJQ0UuIEkgaGF2ZSBu b3cgYWRkZWQgcmVmZXJlbmNlcyB0byBhbGwgb2YgDQp0aGUgdGVybXMgdG8gaW5kaWNhdGUgdGhl aXIgb3JpZ2luLg0KDQo+IFMgMy4NCj4+ICAgICAgIGNvbm5lY3RlZCB0byB0aGUgcHVibGljIElu dGVybmV0LiAgVG8gYmUgY29udGFjdGVkIGZyb20gYmVoaW5kIGEgTkFULA0KPj4gICAgICAgYXQg bGVhc3QgdGhlIFJlc3BvbmRlciBtdXN0IGJlIHJlZ2lzdGVyZWQgd2l0aCBhIENvbnRyb2wgUmVs YXkgU2VydmVyDQo+PiAgICAgICByZWFjaGFibGUgb24gdGhlIHB1YmxpYyBJbnRlcm5ldC4gIFRo ZSBSZXNwb25kZXIgbWF5IGhhdmUgYWxzbw0KPj4gICAgICAgcmVnaXN0ZXJlZCB0byBhIERhdGEg UmVsYXkgU2VydmVyIHRoYXQgY2FuIGZvcndhcmQgdGhlIGRhdGEgcGxhbmUgaW4NCj4+ICAgICAg IGNhc2UgTkFUIHRyYXZlcnNhbCBmYWlscy4gIFdoaWxlLCBzdHJpY3RseSBzcGVha2luZywgdGhl IEluaXRpYXRvcg0KPj4gICAgICAgZG9lcyBub3QgbmVlZCBhbnkgUmVsYXkgU2VydmVycywgaXQg bWF5IGFjdCBpbiB0aGUgb3RoZXIgcm9sZSB3aXRoDQo+IA0KPiBXaHkgZG9lc24ndCBpdCBuZWVk IFJlbGF5IFNlcnZlcnM/IFRoaXMgaXNuJ3QgdHJ1ZSBmb3Igb3JkaW5hcnkgSUNFLg0KDQpnb29k IGNhdGNoLiBBY3R1YWxseSwgQ29udHJvbCBSZWxheSBTZXJ2ZXIgaXMgYWx3YXlzIG5lZWRlZCB0 byBkaXNjb3ZlciANCnNlcnZlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBidXQgRGF0YSBSZWxheSBT ZXJ2ZXIgaXMga2luZCBvZiBvcHRpb25hbC4gSSANCmNoYW5nZWQgdGhlIHRleHQgYXMgZm9sbG93 czoNCg0KV2hpbGUsIHN0cmljdGx5IHNwZWFraW5nLCB0aGUgSW5pdGlhdG9yIGRvZXMgbm90IG5l ZWQgYSBEYXRhIFJlbGF5IA0KU2VydmVyLCBbLi5dDQoNCj4gUyA0LjEuDQo+PiAgICAgICBmb3Ig dGhhdCBob3N0IGFuZCBjbG9zZSB0aGUgY29ycmVzcG9uZGluZyBVRFAgcG9ydCAodW5sZXNzIG90 aGVyIERhdGENCj4+ICAgICAgIFJlbGF5IENsaWVudHMgYXJlIHN0aWxsIHVzaW5nIGl0KS4NCj4+ ICAgIA0KPj4gICAgICAgVGhlIERhdGEgUmVsYXkgU2VydmVyIFNIT1VMRCBvZmZlciBhIGRpZmZl cmVudCByZWxheWVkIGFkZHJlc3MgYW5kDQo+PiAgICAgICBwb3J0IGZvciBlYWNoIERhdGEgUmVs YXkgQ2xpZW50IGJlY2F1c2UgdGhpcyBjYW4gY2F1c2UgcHJvYmxlbXMgd2l0aA0KPj4gICAgICAg c3RhdGVmdWwgZmlyZXdhbGxzIChzZWUgU2VjdGlvbiA2LjUpLg0KPiANCj4gYnkgInRoaXMiIEkg dGhpbmsgeW91IG1lYW4gIm5vdCBkb2luZyBzbyINCg0KdGhhbmtzLCBjb3JyZWN0ZWQuDQoNCj4g UyA0LjIuDQo+PiAgICAgICBwYXJhbWV0ZXIgZGlzY292ZXJlZCBkdXJpbmcgdGhlIENvbnRyb2wg UmVsYXkgU2VydmVyIHJlZ2lzdHJhdGlvbiBhcw0KPj4gICAgICAgYSBzZXJ2ZXIgcmVmbGV4aXZl IGNhbmRpZGF0ZS4gIEluIHRoaXMgY2FzZSwgbm8gZnVydGhlciBjYW5kaWRhdGUNCj4+ICAgICAg IGdhdGhlcmluZyBpcyBuZWVkZWQuDQo+PiAgICANCj4+ICAgICAgIEEgRGF0YSBSZWxheSBDbGll bnQgTUFZIHJlZ2lzdGVyIG9ubHkgYSBzaW5nbGUgcmVsYXllZCBjYW5kaWRhdGUgdG8NCj4+ICAg ICAgIGJlIHVzZWQgd2l0aCBtdWx0aXBsZSBvdGhlciBwZWVycy4gIEhvd2V2ZXIsIGl0IGlzIFJF Q09NTUVOREVEIHRoYXQgYQ0KPiANCj4gTml0OiB0aGlzIHdvdWxkIGJlIGNsZWFyZXIgaWYgeW91 IHNhaWQgInRoYXQgaXQgdXNlcyB3aXRoIg0KDQp5ZXMsIHRoYW5rcyENCg0KPiBTIDQuMi4NCj4+ ICAgICAgIGdhdGhlcmluZyBpcyBuZWVkZWQuDQo+PiAgICANCj4+ICAgICAgIEEgRGF0YSBSZWxh eSBDbGllbnQgTUFZIHJlZ2lzdGVyIG9ubHkgYSBzaW5nbGUgcmVsYXllZCBjYW5kaWRhdGUgdG8N Cj4+ICAgICAgIGJlIHVzZWQgd2l0aCBtdWx0aXBsZSBvdGhlciBwZWVycy4gIEhvd2V2ZXIsIGl0 IGlzIFJFQ09NTUVOREVEIHRoYXQgYQ0KPj4gICAgICAgRGF0YSBSZWxheSBDbGllbnQgcmVnaXN0 ZXJzIGEgbmV3IHNlcnZlciByZWZsZXhpdmUgY2FuZGlkYXRlIGZvciBlYWNoDQo+PiAgICAgICBv ZiBpdHMgcGVlciBmb3IgdGhlIHJlYXNvbnMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xMi4zLiAg VGhlDQo+IA0KPiBUaGlzIHNlbnRlbmNlIGZlZWxzIGxpa2UgYSBiaXQgb2YgYSBub24tc2VxdWl0 ZXIuIEhvdyBkbyB5b3UNCj4gInJlZ2lzdGVyIiBhIHNyZmx4PyBPciBzaG91bGQgdGhpcyBzYXkg InJlbGF5ZWQiDQoNCllvdSdyZSByaWdodCwgaXQgc2hvdWxkIHNheSAicmVsYXllZCIuDQoNCj4g UyA0LjIuDQo+PiAgICAgICBkZXBsb3ltZW50cyBpbiBvcmRlciB0byBlbmFibGUgaXQgYnkgc29m dHdhcmUgY29uZmlndXJhdGlvbiB1cGRhdGUgaWYNCj4+ICAgICAgIG5lZWRlZCBhdCBzb21lIHBv aW50LiAgQSBob3N0IFNIT1VMRCBlbXBsb3kgb25seSBhIHNpbmdsZSBzZXJ2ZXIgZm9yDQo+PiAg ICAgICBnYXRoZXJpbmcgdGhlIGNhbmRpZGF0ZXMgZm9yIGEgc2luZ2xlIEhJUCBhc3NvY2lhdGlv bjsgZWl0aGVyIG9uZQ0KPj4gICAgICAgc2VydmVyIHByb3ZpZGluZyBib3RoIENvbnRyb2wgYW5k IERhdGEgUmVsYXkgU2VydmVyIGZ1bmN0aW9uYWxpdHksIG9yDQo+PiAgICAgICBvbmUgQ29udHJv bCBSZWxheSBTZXJ2ZXIgYW5kIGFsc28gRGF0YSBSZWxheSBTZXJ2ZXIgaWYgdGhlDQo+PiAgICAg ICBmdW5jdGlvbmFsaXR5IGlzIG9mZmVyZWQgYnkgYW5vdGhlciBzZXJ2ZXIuICBXaGVuIHRoZSBy ZWxheSBzZXJ2aWNlDQo+IA0KPiBIb3cgZG9lcyB0aGlzIGludGVyYWN0IHdpdGggbXVsdC1sYXll cmVkIE5BVD8+DQoNCk5vIGRpZmZlcmVudCBmcm9tIElDRSB3aXRoIHNlcGFyYXRlZCBTVFVOIGFu ZCBUVVJOIHNlcnZlcnMgbXVsdGktbGF5ZXIgDQpOQVQgc2NlbmFyaW9zLiBTaG91bGQgd2UgbWVu dGlvbiBzb21ldGhpbmcgYWJvdXQgdGhlIGlzc3VlcyByZWxhdGVkIHRvIA0Kc29tZSBzcGVjaWZp YyBzY2VuYXJpbz8NCg0KPiBTIDQuMy4NCj4+ICAgICAgIFNlcnZlcnMgKGUuZy4gaW4gdGhlIGNh c2Ugb2YgYSBzaW5nbGUgc2VydmVyLCBpdCB3b3VsZCBiZSAxKS4gIEENCj4+ICAgICAgIHNtYWxs ZXIgdmFsdWUgdGhhbiA1MDAgbXMgZm9yIHRoZSBSVE8gTVVTVCBOT1QgYmUgdXNlZC4NCj4+ICAg IA0KPj4gICAgNC4zLiAgTkFUIFRyYXZlcnNhbCBNb2RlIE5lZ290aWF0aW9uDQo+PiAgICANCj4+ ICAgICAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHVzYWdlIG9mIGEgbmV3IG5vbi1jcml0 aWNhbCBwYXJhbWV0ZXINCj4gDQo+IENhbiB5b3UgbmFtZSB0aGUgdHlwZSBoZXJlIHBsZWFzZT8N Cg0KSSBjaGFuZ2VkIHRoaXMgYXMgZm9sbG93czoNCg0KVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0 aGUgdXNhZ2Ugb2YgYSBub24tY3JpdGljYWwgcGFyYW1ldGVyIHR5cGUgY2FsbGVkIA0KTkFUX1RS QVZFUlNBTF9NT0RFIHdpdGggYSBuZXcgbW9kZSBjYWxsZWQgSUNFLUhJUC1VRFAuDQoNCj4gUyA1 LjYuDQo+PiAgICAgICAgIFByb3RvY29sICAgSUFOQSBhc3NpZ25lZCwgSW50ZXJuZXQgUHJvdG9j b2wgbnVtYmVyLg0KPj4gICAgICAgICAgICAgICAgICAgIDE3IGZvciBVRFAsIDAgZm9yIHBsYWlu IElQDQo+PiAgICAgICAgIFJlc2VydmVkICAgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2U7IHplcm8g d2hlbiBzZW50LCBpZ25vcmVkDQo+PiAgICAgICAgICAgICAgICAgICAgd2hlbiByZWNlaXZlZA0K Pj4gICAgICAgICBBZGRyZXNzICAgIGFuIElQdjYgYWRkcmVzcyBvciBhbiBJUHY0IGFkZHJlc3Mg aW4gIklQdjQtTWFwcGVkDQo+PiAgICAgICAgICAgICAgICAgICAgSVB2NiBhZGRyZXNzIiBmb3Jt YXQNCj4gDQo+IElzIHRoZXJlIGEgY29uY2VybiBhYm91dCBOQVRzIHJld3JpdGluZyB0aGVzZSwg YXMgd2UgaGFkIGZvciBYT1ItDQo+IE1BUFBFRC1BRERSRVNTDQoNCndlIGRvbid0IG5lY2Vzc2Fy aWx5IG5lZWQgWE9ScmluZyBpbiBISVAsIHdlIGNhbiBhY3R1YWxseSBlbmNyeXB0IA0KcGFyYW1l dGVycy4gSSBoYXZlIHJlcXVlc3RlZCB0aGUgV0cgaWYgaXQgaXMgb2sgdG8gc3dpdGNoIHRvIGVu Y3J5cHRlZCANCnBhcmFtZXRlcnMgLSBzaG91bGQgYmUgb2sgSSBiZWxpZXZlLg0KDQpUaGUgb3Jp Z2luYWwgcmVhc29uIHRvIGtlZXAgdGhlIGxvY2F0b3JzIChhbmQgbWFueSBvdGhlciBISVAgcGFy YW1ldGVycykgDQppbiBwbGFpbnRleHQgd2FzIG1pZGRsZWJveCB0cmFuc3BhcmVuY3kgYnV0IEkg Z3Vlc3MgaW4gaGVyZSB3ZSBoYXZlIGEgDQpnb29kIHJlYXNvbiB0byBicmVhayBpdC4NCg0KPiBT IDUuNy4NCj4+ICAgICAgIHwgUmVzZXJ2ZWQgIHwgMCAgICAgICAgfCBSZXNlcnZlZCBmb3IgZnV0 dXJlIGV4dGVuc2lvbnMgICAgICAgICAgICAgfA0KPj4gICAgICAgfCBQcmVmZXJyZWQgfCAwIG9y IDEgICB8IFNldCB0byAxIGZvciBhIExvY2F0b3IgaW4gUjEgaWYgdGhlICAgICAgICB8DQo+PiAg ICAgICB8IChQKSBiaXQgICB8ICAgICAgICAgIHwgUmVzcG9uZGVyIGNhbiB1c2UgaXQgZm9yIHRo ZSByZXN0IG9mIHRoZSAgIHwNCj4+ICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCBiYXNl IGV4Y2hhbmdlLCBvdGhlcndpc2Ugc2V0IHRvIHplcm8gICAgICAgfA0KPj4gICAgICAgfCBMb2Nh dG9yICAgfCBWYXJpYWJsZSB8IExvY2F0b3IgbGlmZXRpbWUgaW4gc2Vjb25kcyAgICAgICAgICAg ICAgICB8DQo+PiAgICAgICB8IExpZmV0aW1lICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gDQo+IFdoYXQgaXMgdGhlIHB1cnBvc2Ug b2YgdGhpcz8gSXQncyBub3QgYW4gSUNFIHBhcmFtZXRlci4NCg0KSW4gSElQLCBsb2NhdG9ycyBo YXZlIGEgbWF4aW11bSBsaWZldGltZSBhZnRlciB3aGljaCB0aGV5IGJlY29tZSANCmRlcHJlY2F0 ZWQgKFJGQzgwNDYpLiBTaG91bGQgYWRkIHNvbWV0aGluZyBoZXJlPw0KDQo+IFMgNS43Lg0KPj4g ICAgICAgfCBQb3J0ICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQo+PiAgICAgICB8IFRyYW5zcG9ydCB8IFZhcmlhYmxlIHwgSUFO QSBhc3NpZ25lZCwgdHJhbnNwb3J0IGxheWVyIEludGVybmV0ICAgIHwNCj4+ICAgICAgIHwgUHJv dG9jb2wgIHwgICAgICAgICAgfCBQcm90b2NvbCBudW1iZXIuICBDdXJyZW50bHkgb25seSBVRFAg KDE3KSAgfA0KPj4gICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8IGlzIHN1cHBvcnRlZC4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICAgICB8IEtpbmQgICAgICB8IFZh cmlhYmxlIHwgMCBmb3IgaG9zdCwgMSBmb3Igc2VydmVyIHJlZmxleGl2ZSwgMiBmb3IgIHwNCj4+ ICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfCBwZWVyIHJlZmxleGl2ZSBvciAzIGZvciBy ZWxheWVkIGFkZHJlc3MgICAgfA0KPiANCj4gV2h5IGRvIHlvdSBuZWVkIHRvIHNlbmQgcHJmbHgg Y2FuZGlkYXRlcz8NCg0KVGhpcyBpcyByZXNpZHVhbCBmcm9tIFJGQzU3NzAgZnJvbSB3aGVyZSBp dCB3YXNuJ3QgdXNlZCBlaXRoZXIuIEkgYWRkZWQgDQphIG5vdGUgaGVyZSB0aGF0IGtpbmQgMiBp cyBjdXJyZW50bHkgdW51c2VkLg0KDQo+IFMgMTAuMi4NCj4+ICAgICAgIG8gIElmIHRoZSBhZ2Vu dCBpcyB1c2luZyBEaWZmc2VydiBDb2RlcG9pbnQgbWFya2luZ3MgW1JGQzI0NzVdIGluIGl0cw0K Pj4gICAgICAgICAgbWVkaWEgcGFja2V0cywgaXQgU0hPVUxEIGFwcGx5IHRob3NlIHNhbWUgbWFy a2luZ3MgdG8gaXRzDQo+PiAgICAgICAgICBjb25uZWN0aXZpdHkgY2hlY2tzLg0KPj4gICAgDQo+ PiAgICAgICBvICBVbmxpa2UgaW4gSUNFLCB0aGUgYWRkcmVzc2VzIGFyZSBub3QgWE9SLWVkIGlu IE5hdGl2ZSBJQ0UtSElQDQo+PiAgICAgICAgICBwcm90b2NvbCBpbiBvcmRlciB0byBhdm9pZCBt aWRkbGVib3ggdGFtcGVyaW5nLg0KPiANCj4gSSBub3RlZCB0aGlzIGVhcmxpZXIuIFdoeT8NCg0K U2VlIG15IGVhcmxpZXIgY29tbWVudCwgSSB3b3VsZCBjaGFuZ2UgdGhpcyB0bzoNCg0KVW5saWtl IGluIElDRSwgdGhlIGFkZHJlc3NlcyBhcmUgbm90IFhPUi1lZCBpbiBOYXRpdmUgSUNFLUhJUCAN CiANCg0KcHJvdG9jb2wgYnV0IHJhdGhlciBlbmNyeXB0ZWQgdG8gYXZvaWQgbWlkZGxlYm94IHRh bXBlcmluZy4NCg== From nobody Thu Nov 8 08:22:21 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69BB12D4E6 for ; Thu, 8 Nov 2018 08:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Wf6jHYlWGe19 for ; Thu, 8 Nov 2018 08:22:18 -0800 (PST) Received: from out.west.exch081.serverdata.net (cas081-co-1.exch081.serverdata.net [199.193.204.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1899412D4EE for ; Thu, 8 Nov 2018 08:22:17 -0800 (PST) Received: from MBX081-W5-CO-2.exch081.serverpod.net (10.224.129.85) by MBX081-W5-CO-1 (10.224.129.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 8 Nov 2018 08:22:16 -0800 Received: from MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) by MBX081-W5-CO-2.exch081.serverpod.net ([10.224.129.85]) with mapi id 15.00.1367.000; Thu, 8 Nov 2018 08:22:16 -0800 From: Jeff Ahrenholz To: Miika Komu , hip WG Thread-Topic: [Hipsec] IESG review of NAT traversal draft and encrypted parameters Thread-Index: AQHUd383rljQQyA9SU6NRqaWcQec9Q== Date: Thu, 8 Nov 2018 16:22:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.168.34.194] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Hipsec] IESG review of NAT traversal draft and encrypted parameters X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 16:22:20 -0000 TWlpa2EsDQoNCj4gICAgSSBkb24ndCB0aGluayB3ZSBuZWVkIFhPUnJpbmcgd2l0aCBISVAgYmVj YXVzZSB3ZSBoYXZlIG1vcmUgcG93ZXJmdWwgDQo+ICAgIG1lY2hhbmlzbXMgaW4gSElQLiBTbywg SSBhbSBnb2luZyB0byBhZGQgc29tZSB0ZXh0IHRoYXQgbWFuZGF0ZXMgdGhhdCANCj4gICAgdGhl IExPQ0FUT1IgcGFyYW1ldGVyIG11c3QgYmUgZW5jYXBzdWxhdGVkIGluc2lkZSBFTkNSWVBURUQg cGFyYW1ldGVyIA0KPiAgICB3aGVuIElDRS1ISVAtVURQIHdpbGwgYmUgdXNlZC4gVGhlIHRyYWRl b2ZmIGhlcmUgaXMgdGhhdCB3ZSBmYXZvciANCj4gICAgZW5kLWhvc3QgcHJpdmFjeSBhdCB0aGUg Y29zdCBtaWRkbGVib3ggdHJhbnNwYXJlbmN5Lg0KDQpTZWVtcyBsaWtlIGEgZ29vZCB1c2Ugb2Yg RU5DUllQVEVEIHRvIG1lLg0KDQpJJ20gbm90IHN1cmUgd2hhdCBraW5kIG9mIG1pZGRsZWJveCB3 b3VsZCBuZWVkIHRvIGtub3cgYWxsIG9mIHRoZSBhZGRyZXNzIGNhbmRpZGF0ZXMuIE1heWJlIHNv bWUgZXh0cmEgc2lnbmFsaW5nIGNvdWxkIGJlIGRldmlzZWQgd2hlbiB0aGF0IG5lZWRzIHRvIGhh cHBlbiAobGlrZSBhIEhJUC1hd2FyZSBtaWRkbGVib3ggd2hlcmUgYWRkcmVzc2VzIGNhbiBiZSBj b21tdW5pY2F0ZWQgdmlhIEhJUC4pDQoNClRoYW5rcyBmb3IgY29udGludWluZyB0aGUgd29yayBv biB0aGlzIQ0KDQotSmVmZg0KDQo= From nobody Wed Nov 21 11:37:58 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1CB130DDC for ; Wed, 21 Nov 2018 11:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Hh_agKyHMDow for ; Wed, 21 Nov 2018 11:37:47 -0800 (PST) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 478EC130DC8 for ; Wed, 21 Nov 2018 11:37:43 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id 83-v6so5854801ljf.10 for ; Wed, 21 Nov 2018 11:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3LK142W7EP3l15nRJP3/XmTmgzFdMmYLA0VSDHcp3Lc=; b=yguk1960pp1C8Ch72ludNRhUwFrPVtYFIPMdKmQrb9H1D+HrLK5N2RBFOUDf/tpu3q PJj8I0R1j9QkFttfRu4VnwNzQ9sSqb2wM1zVTa9VuGhrjDlsC1oFBQ67vRBX1BpmSWIy SZOctMMtM1jNw7litXy8R5PN+S2johRfKjtyZWK4c00Pe4TYelGOX5FwLXoCPxSwQaAA wXYADsDihW1/T3HJzMEhKAgm5oa/pUIBWbBYi/lpnO4LXQO3gVrrCucxieK2bgh00D1E r/LQ6jJcd0RwHkTITwTGm++sXPNprpLW9NdQHWCvm/DFrdBMfxZIgbU0mke1S1NKYf5A BFvQ== 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=3LK142W7EP3l15nRJP3/XmTmgzFdMmYLA0VSDHcp3Lc=; b=pC5u1LUV4PjTj5gObKyrx+7/VtGOz+1gGWuXAVLf/jeIGQodqURChoH9KYdDL/oupM QlMV4PQGGUOdO71UdU7tuoNzi9SrCpOZIpOlCHjxH01K9CcMfJIr6ZWD4qKrRFKW/EQ5 kJkmFK14vOgVezKCi9vpuNBbAAaOA9Vuhxej8DopxHefNXHtfTLgctBFvxFoM5/TLgmD /w5Ow3DtLwDv5RknPS/jrbMI56SSDtJpsQCbnbeTjDp2an79kulBcN6WHsf9EsQBz5/Y rzFGRpghaXjVTXzx5nYxQmBowCnYpytIOMwfnxxtuGSa7B37BMDnZFGEr5vIrHnNotRv CVjg== X-Gm-Message-State: AA+aEWZ3XQ6GRUHOra5KfC4TMZG8wvPDzh6RBTbXDy3652XgJi2BCC+w c29hqukO5T364fvrV0BsVQXQ2JCa10LgSx2j412yQA== X-Google-Smtp-Source: AFSGD/Uo+E220Osfj1uCqruCqfGi1XTJqIvgVCCS/KttbzZVmQlHx4ywtCU654ivTGPhakCXYanz9yM7akOsqX03YxA= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr5321430ljb.51.1542829061372; Wed, 21 Nov 2018 11:37:41 -0800 (PST) MIME-Version: 1.0 References: <152564286489.26793.2457846656783140871.idtracker@ietfa.amsl.com> <70e4c94f-0097-0b13-140c-db0a5732ab67@kapsi.fi> In-Reply-To: <70e4c94f-0097-0b13-140c-db0a5732ab67@kapsi.fi> From: Eric Rescorla Date: Wed, 21 Nov 2018 11:37:03 -0800 Message-ID: To: mkomu@kapsi.fi Cc: IESG , hipsec@ietf.org, Gonzalo Camarillo , draft-ietf-hip-rfc4423-bis@ietf.org, hip-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000002711c2057b31e2d6" Archived-At: Subject: Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 19:37:50 -0000 --0000000000002711c2057b31e2d6 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 12:07 PM Miika Komu wrote: > Hi Eric, > > On 5/7/18 00:41, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-hip-rfc4423-bis-19: 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-hip-rfc4423-bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3709 > > > > > > Maybe I'm missing something important, but I don't see in this > > document how you go from a HI (or HIT) to the corresponding IP > > locator. That seems pretty critical to making this work. Can you point > > me in the right direction? > > (I interpret "right" direction here as how to implement this in > practice; please let me know if you were asking for something else) > > Existing applications can utilize LSIs or HITs, for instance, via > /etc/hosts in Linux or if the developer/user uses them directly. > Mappings can be configured manually. A better way is to use ,e.g., DNS > to store the FQDN, HIs, IP address mappings: > > https://tools.ietf.org/html/rfc8005 > > An application can receive LSIs or HITs from DNS queries when a HI > record exists for a host. This can be implemented in the local resolver > library (e.g. glibc in Linux) supports it and sends the HI-to-IP address > mapping to the local HIP daemon. As an alternative implementation > technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux): > > https://tools.ietf.org/html/rfc6538#section-4.1 > > As yet another alternative, RFC5338 (section 3.2) suggests interposing > HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in > Linux) that translate HIs into LSIs and HITs to the application and > cache the IP address mapping to the HIP daemon: > > https://tools.ietf.org/html/rfc5338#section-3.2 > > That's all for existing applications. New HIP native applications could > use DNS library extensions for getaddrinfo() that would be implemented > e.g. in glibc in Linux: > > https://tools.ietf.org/html/rfc6317 > > All of the mentioned references are mentioned in the draft. Should I add > something more compressed along these lines of text or is this too > detailed? > Maybe I'm missing something, but it seems like this is not an interoperable state of affairs. > IMPORTANT > > S 11.3.1. > >> avoiding manual configurations. The three components are further > >> described in the HIP experiment report [RFC6538]. > >> > >> Based on the interviews, Levae et al suggest further directions to > >> facilitate HIP deployment. Transitioning the HIP specifications > to > >> the standards track may help, but other measures could be taken. > As > > > > This confuses me, because we seem to be looking to advance some of the > > HIP specs (e.g., hip-dex) at PS > > Can you elaborate? And do you mean protocol stack by PS? > Proposed Standard. > > COMMENTS > > S 3.1. > >> were obtained. For 64 bits, this number is roughly 4 > billion. A > >> hash size of 64 bits may be too small to avoid collisions in a > >> large population; for example, there is a 1% chance of > collision > >> in a population of 640M. For 100 bits (or more), we would not > >> expect a collision until approximately 2**50 (1 quadrillion) > >> hashes were generated. > > > > It's not just a matter of collisions being hard, but also of being > > difficult to produce an HI with a given name. > > ...where name would be the hash (i.e. HIT). So I added: > > Besides accidental collisions, it is also worth noting that intentional > collisions are difficult to accomplish because generating a valid, > colliding hash along with its private-public key is computationally > challenging. > > Did I capture your thinking correctly? > Well, this isn't a collision; it's what's called a preimage. I.e., computing a public key with a given HIT. Anyway, as far as I can tell, in HIP being able to compute a preimage for HIT Y = H(K_X) is equivalent to breaking key K_X, so that means that that function must have reasonable strength. 2^64 is nowhere near enough and the typical expected security level of IETF protocols is 2^128, so that means that the full width of the IPv6 address has to be used. > S 4. > >> 'well known', some unpublished or 'anonymous'. A system may self- > >> assert its own identity, or may use a third-party authenticator > like > >> DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity > assertion > >> to another namespace. It is expected that the Host Identifiers > will > >> initially be authenticated with DNSSEC and that all > implementations > >> will support DNSSEC as a minimal baseline. > > > > This wasn't a very good assumption when 4423 was published, and it > > seems even worse now, given the low rate of deployment of DNSSEC and > > the fact that we know many middleboxes break DNSSEC. > > Then I guess it would be fine to remove the last sentence? > Yes, I think that would be good to do. > > S 4.3. > >> packet. Consequently, a HIT should be unique in the whole IP > >> universe as long as it is being used. In the extremely rare case > of > >> a single HIT mapping to more than one Host Identity, the Host > >> Identifiers (public keys) will make the final difference. If > there > >> is more than one public key for a given node, the HIT acts as a > hint > >> for the correct public key to use. > > > > How do you handle second-preimage attacks on the hash? > > I guess you are referring to this: > > https://tools.ietf.org/html/rfc7343#section-5 > > (Please let me know if an explicit reference is needed) > No, I'm referring to the point I raised above. > > S 5.1. > >> At the server side, utilizing DNS is a better alternative than a > >> shared Host Identity to implement load balancing. A single FQDN > >> entry can be configured to refer to multiple Host Identities. > Each > >> of the FQDN entries can be associated with the related locators, > or a > >> single shared locator in the case the servers are using the same > HIP > >> rendezvous server Section 6.3 or HIP relay server Section 6.4. > > > > This is becoming a less common practice. How do you handle anycast, > > which is the modern practice? > > I added the following statement: > > "It is also worth noting that opportunistic mode is also required > > > in practice when anycast IP addresses would be utilized as locators:" > > Does this address your concern? > > Btw, opportunistic mode is further described in the following documents: > I'm not following how this solves the problem. It seems like you're still going to get badly suboptimal routing. -Ekr > Existing apps: > > https://tools.ietf.org/html/rfc6538#section-2.3.2 > https://tools.ietf.org/html/rfc5338#section-3.2 > > HIP native apps: > > https://tools.ietf.org/html/rfc6317#section-4.1.1 > > > S 7. > >> > >> The encapsulation format for the data plane used for carrying the > >> application-layer traffic can be dynamically negotiated during the > >> key exchange. For instance, HICCUPS extensions [RFC6078] define > one > >> way to transport application-layer datagrams directly over the HIP > >> control plane, protected by asymmetric key cryptography. Also, > S-RTP > > > > Nit: SRTP, no hyphen > > Thanks, fixed! > --0000000000002711c2057b31e2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Nov 20, 2018 at 12:07 PM Miika Komu <mkomu@kapsi.fi> wrote:
Hi E= ric,

On 5/7/18 00:41, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-hip-rfc4423-bis-19: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dr= aft-ietf-hip-rfc4423-bis/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3709<= /a>
>
>
> Maybe I'm missing something important, but I don't see in this=
> document how you go from a HI (or HIT) to the corresponding IP
> locator. That seems pretty critical to making this work. Can you point=
> me in the right direction?

(I interpret "right" direction here as how to implement this in <= br> practice; please let me know if you were asking for something else)

Existing applications can utilize LSIs or HITs, for instance, via
/etc/hosts in Linux or if the developer/user uses them directly.
Mappings can be configured manually. A better way is to use ,e.g., DNS
to store the FQDN, HIs, IP address mappings:

https://tools.ietf.org/html/rfc8005

An application can receive LSIs or HITs from DNS queries when a HI
record exists for a host. This can be implemented=C2=A0 in the local resolv= er
library (e.g. glibc in Linux) supports it and sends the HI-to-IP address mapping to the local HIP daemon. As an alternative implementation
technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux):
https://tools.ietf.org/html/rfc6538#section-4.1
As yet another alternative, RFC5338 (section 3.2) suggests interposing
HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq"= ; in
Linux) that translate HIs into LSIs and HITs to the application and
cache the IP address mapping to the HIP daemon:

https://tools.ietf.org/html/rfc5338#section-3.2
That's all for existing applications. New HIP native applications could=
use DNS library extensions for getaddrinfo() that would be implemented
e.g. in glibc in Linux:

https://tools.ietf.org/html/rfc6317

All of the mentioned references are mentioned in the draft. Should I add something more compressed along these lines of text or is this too detailed= ?

Maybe I'm missing something, but = it seems like this is not an interoperable state of affairs.

=

> IMPORTANT
> S 11.3.1.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding manual configurations.=C2=A0 Th= e three components are further
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0described in the HIP experiment report [= RFC6538].
>>=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Based on the interviews, Levae et al sug= gest further directions to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0facilitate HIP deployment.=C2=A0 Transit= ioning the HIP specifications to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standards track may help, but other = measures could be taken.=C2=A0 As
>
> This confuses me, because we seem to be looking to advance some of the=
> HIP specs (e.g., hip-dex) at PS

Can you elaborate? And do you mean protocol stack by PS?

Proposed Standard.

=C2=A0
=
> COMMENTS
> S 3.1.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 were obtained.=C2=A0 For 64 bits= , this number is roughly 4 billion.=C2=A0 A
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hash size of 64 bits may be too = small to avoid collisions in a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 large population; for example, t= here is a 1% chance of collision
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in a population of 640M.=C2=A0 F= or 100 bits (or more), we would not
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expect a collision until approxi= mately 2**50 (1 quadrillion)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hashes were generated.
>
> It's not just a matter of collisions being hard, but also of being=
> difficult to produce an HI with a given name.

...where name would be the hash (i.e. HIT). So I added:

Besides accidental collisions, it is also worth noting that intentional collisions are difficult to accomplish because generating a valid,
colliding hash along with its private-public key is computationally
challenging.

Did I capture your thinking correctly?

= Well, this isn't a collision; it's what's called a preimage. I.= e., computing a public
key with a given HIT. Anyway, as far as I = can tell, in HIP being able to compute
a preimage for HIT Y =3D H= (K_X) is equivalent to breaking key K_X, so that means
that that = function must have reasonable strength. 2^64 is nowhere near
enou= gh and the typical expected security level of IETF protocols is 2^128,
so that means that the full width of the IPv6 address has to be used.=



> S 4.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0'well known', some unpublished o= r 'anonymous'.=C2=A0 A system may self-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0assert its own identity, or may use a th= ird-party authenticator like
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0DNSSEC [RFC2535], PGP, or X.509 to '= notarize' the identity assertion
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0to another namespace.=C2=A0 It is expect= ed that the Host Identifiers will
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0initially be authenticated with DNSSEC a= nd that all implementations
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0will support DNSSEC as a minimal baselin= e.
>
> This wasn't a very good assumption when 4423 was published, and it=
> seems even worse now, given the low rate of deployment of DNSSEC and > the fact that we know many middleboxes break DNSSEC.

Then I guess it would be fine to remove the last sentence?
=


Yes, I think that would be good to do.


> S 4.3.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 Consequently, a HIT should= be unique in the whole IP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0universe as long as it is being used.=C2= =A0 In the extremely rare case of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0a single HIT mapping to more than one Ho= st Identity, the Host
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Identifiers (public keys) will make the = final difference.=C2=A0 If there
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is more than one public key for a given = node, the HIT acts as a hint
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the correct public key to use.
>
> How do you handle second-preimage attacks on the hash?

I guess you are referring to this:

https://tools.ietf.org/html/rfc7343#section-5

(Please let me know if an explicit reference is needed)

No, I'm referring to the point I raised above.

=C2=A0
> S 5.1.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0At the server side, utilizing DNS is a b= etter alternative than a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0shared Host Identity to implement load b= alancing.=C2=A0 A single FQDN
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0entry can be configured to refer to mult= iple Host Identities.=C2=A0 Each
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the FQDN entries can be associated wi= th the related locators, or a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0single shared locator in the case the se= rvers are using the same HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0rendezvous server Section 6.3 or HIP rel= ay server Section 6.4.
>
> This is becoming a less common practice. How do you handle anycast, > which is the modern practice?

I added the following statement:

"It is also worth noting that opportunistic mode is also required


in practice when anycast IP addresses would be utilized as locators:"<= br>
Does this address your concern?

Btw, opportunistic mode is further described in the following documents:

I'm not following how this solves the= problem. It seems like you're still going to get
badly subop= timal routing.

-Ekr


Existing apps:

https://tools.ietf.org/html/rfc6538#section-2.3.2
https://tools.ietf.org/html/rfc5338#section-3.2
HIP native apps:

https://tools.ietf.org/html/rfc6317#section-4.1.1

> S 7.
>>=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The encapsulation format for the data pl= ane used for carrying the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0application-layer traffic can be dynamic= ally negotiated during the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0key exchange.=C2=A0 For instance, HICCUP= S extensions [RFC6078] define one
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0way to transport application-layer datag= rams directly over the HIP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0control plane, protected by asymmetric k= ey cryptography.=C2=A0 Also, S-RTP
>
> Nit: SRTP, no hyphen

Thanks, fixed!
--0000000000002711c2057b31e2d6-- From mkomu@kapsi.fi Tue Nov 20 12:07:16 2018 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E69E130EF2; Tue, 20 Nov 2018 12:07:16 -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, RCVD_IN_DNSWL_LOW=-0.7, 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=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGnCpnsXP_RT; Tue, 20 Nov 2018 12:07:12 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 55E86130E8F; Tue, 20 Nov 2018 12:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From: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=lDDV8VNcpv1Iw6xr3aeDGiXDJGktxKvwVXZ0RlKZWAM=; b=fpjd8945r17EJiXSfYA2/7vO8b BUa929eR2nM7vV7XIMj8HTD3mw10xIMjFycp71dxDkAp9J+od5XnPjMnPZ/boSVtpt5apwL0OG083 SigTe+7BarOzRvaKFeE00p9C+aGv0hZ1Se0IuodnfthxLfw+MT8FkhUdlG2Wxb81LLxRzHJ8FUqYs ILHEAwTQ9j3sk+rxe/xK7ixlwQ4jKdlTNbYOcFWOhgrnoydA5qR7Yl22U8YejdgPlB6rslvMlclaC Nxc/e0zj6QfB14NXMrXWPq95b8h0bm4JezTCLIgE2YHc9a7lF9sqr1MGGVbs0mgIDCxRupi9LISsN zmpJkcdw==; Received: from kapsi.fi ([91.232.154.11] helo=[127.0.0.1]) by mail.kapsi.fi with esmtp (Exim 4.89) (envelope-from ) id 1gPCIb-0002o2-IR; Tue, 20 Nov 2018 22:07:05 +0200 From: Miika Komu To: Eric Rescorla , The IESG Cc: hipsec@ietf.org, Gonzalo Camarillo , draft-ietf-hip-rfc4423-bis@ietf.org, hip-chairs@ietf.org References: <152564286489.26793.2457846656783140871.idtracker@ietfa.amsl.com> Message-ID: <70e4c94f-0097-0b13-140c-db0a5732ab67@kapsi.fi> Date: Tue, 20 Nov 2018 22:07:05 +0200 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: <152564286489.26793.2457846656783140871.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 91.232.154.11 X-SA-Exim-Mail-From: mkomu@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Thu, 22 Nov 2018 05:47:18 -0800 Subject: Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 20:10:46 -0000 Hi Eric, On 5/7/18 00:41, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-hip-rfc4423-bis-19: 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-hip-rfc4423-bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3709 > > > Maybe I'm missing something important, but I don't see in this > document how you go from a HI (or HIT) to the corresponding IP > locator. That seems pretty critical to making this work. Can you point > me in the right direction? (I interpret "right" direction here as how to implement this in practice; please let me know if you were asking for something else) Existing applications can utilize LSIs or HITs, for instance, via /etc/hosts in Linux or if the developer/user uses them directly. Mappings can be configured manually. A better way is to use ,e.g., DNS to store the FQDN, HIs, IP address mappings: https://tools.ietf.org/html/rfc8005 An application can receive LSIs or HITs from DNS queries when a HI record exists for a host. This can be implemented in the local resolver library (e.g. glibc in Linux) supports it and sends the HI-to-IP address mapping to the local HIP daemon. As an alternative implementation technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux): https://tools.ietf.org/html/rfc6538#section-4.1 As yet another alternative, RFC5338 (section 3.2) suggests interposing HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in Linux) that translate HIs into LSIs and HITs to the application and cache the IP address mapping to the HIP daemon: https://tools.ietf.org/html/rfc5338#section-3.2 That's all for existing applications. New HIP native applications could use DNS library extensions for getaddrinfo() that would be implemented e.g. in glibc in Linux: https://tools.ietf.org/html/rfc6317 All of the mentioned references are mentioned in the draft. Should I add something more compressed along these lines of text or is this too detailed? > IMPORTANT > S 11.3.1. >> avoiding manual configurations. The three components are further >> described in the HIP experiment report [RFC6538]. >> >> Based on the interviews, Levae et al suggest further directions to >> facilitate HIP deployment. Transitioning the HIP specifications to >> the standards track may help, but other measures could be taken. As > > This confuses me, because we seem to be looking to advance some of the > HIP specs (e.g., hip-dex) at PS Can you elaborate? And do you mean protocol stack by PS? (This text is based on the subjective opinions of the interviewed people. So I don't think it matters so much) > COMMENTS > S 3.1. >> were obtained. For 64 bits, this number is roughly 4 billion. A >> hash size of 64 bits may be too small to avoid collisions in a >> large population; for example, there is a 1% chance of collision >> in a population of 640M. For 100 bits (or more), we would not >> expect a collision until approximately 2**50 (1 quadrillion) >> hashes were generated. > > It's not just a matter of collisions being hard, but also of being > difficult to produce an HI with a given name. ...where name would be the hash (i.e. HIT). So I added: Besides accidental collisions, it is also worth noting that intentional collisions are difficult to accomplish because generating a valid, colliding hash along with its private-public key is computationally challenging. Did I capture your thinking correctly? > S 4. >> 'well known', some unpublished or 'anonymous'. A system may self- >> assert its own identity, or may use a third-party authenticator like >> DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion >> to another namespace. It is expected that the Host Identifiers will >> initially be authenticated with DNSSEC and that all implementations >> will support DNSSEC as a minimal baseline. > > This wasn't a very good assumption when 4423 was published, and it > seems even worse now, given the low rate of deployment of DNSSEC and > the fact that we know many middleboxes break DNSSEC. Then I guess it would be fine to remove the last sentence? > S 4.3. >> packet. Consequently, a HIT should be unique in the whole IP >> universe as long as it is being used. In the extremely rare case of >> a single HIT mapping to more than one Host Identity, the Host >> Identifiers (public keys) will make the final difference. If there >> is more than one public key for a given node, the HIT acts as a hint >> for the correct public key to use. > > How do you handle second-preimage attacks on the hash? I guess you are referring to this: https://tools.ietf.org/html/rfc7343#section-5 (Please let me know if an explicit reference is needed) > S 5.1. >> At the server side, utilizing DNS is a better alternative than a >> shared Host Identity to implement load balancing. A single FQDN >> entry can be configured to refer to multiple Host Identities. Each >> of the FQDN entries can be associated with the related locators, or a >> single shared locator in the case the servers are using the same HIP >> rendezvous server Section 6.3 or HIP relay server Section 6.4. > > This is becoming a less common practice. How do you handle anycast, > which is the modern practice? I added the following statement: "It is also worth noting that opportunistic mode is also required in practice when anycast IP addresses would be utilized as locators:" Does this address your concern? Btw, opportunistic mode is further described in the following documents: Existing apps: https://tools.ietf.org/html/rfc6538#section-2.3.2 https://tools.ietf.org/html/rfc5338#section-3.2 HIP native apps: https://tools.ietf.org/html/rfc6317#section-4.1.1 > S 7. >> >> The encapsulation format for the data plane used for carrying the >> application-layer traffic can be dynamically negotiated during the >> key exchange. For instance, HICCUPS extensions [RFC6078] define one >> way to transport application-layer datagrams directly over the HIP >> control plane, protected by asymmetric key cryptography. Also, S-RTP > > Nit: SRTP, no hyphen Thanks, fixed!