From nobody Mon Dec 17 04:37:29 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 6CBB31294D7 for ; Mon, 17 Dec 2018 04:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 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_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=Gl7VUIKE; dkim=pass (1024-bit key) header.d=ericsson.com header.b=fRpbc9Kf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47y0va-I0jRi for ; Mon, 17 Dec 2018 04:37:20 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6A293128D68 for ; Mon, 17 Dec 2018 04: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=1545050235; x=1547642235; 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=3grXRkuJG7qK6NXEWAFAMNwfbIzITPbe0vTvJErRXRE=; b=Gl7VUIKERYaT2/fZKRT/WaDspjFsYE+m1ZwhG6skcVTatf4eO6BbGyjwdnBotDLH 5q2FGNkXt1SiN5BFDCFbUJXuclUT/efwIXI8meUrLVUGX1ooZwzweqUFegMzbr6+ ExLax39OTs1m8uQpCWMKAzd3PjsFJZM1RuOIMNIDk+Q=; X-AuditID: c1b4fb2d-2198b9e00000062f-cc-5c17987b4e49 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.FF.01583.B78971C5; Mon, 17 Dec 2018 13:37:15 +0100 (CET) Received: from ESESSMB504.ericsson.se (153.88.183.122) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 17 Dec 2018 13:37:13 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) 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, 17 Dec 2018 13:37:13 +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=3grXRkuJG7qK6NXEWAFAMNwfbIzITPbe0vTvJErRXRE=; b=fRpbc9Kf0lDl0tzG6TP5qzvBd3rlfZJIf29YMVcQR7KQkJC5HBTaHyGEo6YRmsXodKW5y5d+FI9Sl73YZlQ9h8hh5fvZoDZQul6e0Q5VO2HWG2T7eEoHtrVcaecsEl5dw4+ad3RPhsK0vERs/SRhXLN1ybgWZzyMr/Pho2ewTPo= Received: from VI1PR0701MB2957.eurprd07.prod.outlook.com (10.173.72.135) by VI1PR0701MB2077.eurprd07.prod.outlook.com (10.167.210.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Mon, 17 Dec 2018 12:37:12 +0000 Received: from VI1PR0701MB2957.eurprd07.prod.outlook.com ([fe80::116c:b456:232b:a2ea]) by VI1PR0701MB2957.eurprd07.prod.outlook.com ([fe80::116c:b456:232b:a2ea%3]) with mapi id 15.20.1446.015; Mon, 17 Dec 2018 12:37:12 +0000 From: Miika Komu To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-hip-rfc4423-bis@ietf.org" , Gonzalo Camarillo , "hip-chairs@ietf.org" , "hipsec@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-hip-rfc4423-bis-19:_(with_COMMENT)?= Thread-Index: AQHT5glFynvGcTsE0Eaw/ZSl33KifaWEPlgA Date: Mon, 17 Dec 2018 12:37:12 +0000 Message-ID: <64c22106-3396-3771-e316-5acca78ff5f0@ericsson.com> References: <152570055924.1427.16939102336092145446.idtracker@ietfa.amsl.com> In-Reply-To: <152570055924.1427.16939102336092145446.idtracker@ietfa.amsl.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM5PR06CA0017.eurprd06.prod.outlook.com (2603:10a6:206:2::30) To VI1PR0701MB2957.eurprd07.prod.outlook.com (2603:10a6:800:87::7) 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; VI1PR0701MB2077; 6:8sqTdlfkVuQ9oPrFbMG3iktgN21xMpWW4rhm+lVlsxtm34t32nSDw14aE0zYoPxgLCOEUk6g6BoO18IWvDLA9lzfPDYsZGqB5JLyG0KFJxbmaWpGZk28BPFt0pqtCf02Nfq7HA5joABxt6nW/8QD/AnwL3aKFbsfMMO/sh07nB7nUH8SjdZYzpogoNtvk9+gL96qv8oE107qRAZdh+deMQnep7yI6azVJw/zvYGg1HH4xraBP6M9PL/c0s8FegAPeKB5RqiUHFJ0Lo3dtmqx9Fg3zKwPzniFfF0quqyP7Fm0YE0hoauF9gn64hsRZanphNq21R5B8reIVQUsgytMHth0GZwhrhRlWsT1Uim4MQFyVLGcGILTflqvqTGST9Kwr5YkHzxAuHFudgreiaJanq/+IwygyddUR+EnEOELPw4XXS5tcJQfATLWWlLuSL+1ofB6NF7vaX3MEt9NjpTi0w==; 5:rKUBBd7T07dqg67fLKHpiCy1US81A1xbiWz6QWs/i+TdrY5n7a7dUAxftZdUSBiP6Cie1sOegu37JbbbKMHqOU5VUYYRQlaAJTtHDIsmuqoeNj/JzB8021qEXRm8XmQvjgmrHepGNtpqiuUkfJEsXprXZjYgnE0Z/4ojFBYgDKE=; 7:WUMR+wodo80R2wiUKOXYLHhRE8GRx2xemzQUoRY/1OZQK7h6Y4gzx5MClfnh5LJYa+GLYSHXvpkWdbGN62Ok+Vy+2WqupGNzirUoHcVhKRBczCmd/zP4xe+KOM8u3BMgf6CUYl5C2e74xRGmbKPmFQ== x-ms-office365-filtering-correlation-id: 723e1017-ef80-4acc-2c80-08d6641c5e1f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2077; x-ms-traffictypediagnostic: VI1PR0701MB2077: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2077; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2077; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(346002)(366004)(376002)(199004)(189003)(31686004)(305945005)(99286004)(52116002)(102836004)(106356001)(53546011)(6486002)(224303003)(6512007)(76176011)(44832011)(224313004)(26005)(6506007)(386003)(7736002)(6306002)(14444005)(256004)(966005)(6246003)(4326008)(105586002)(14454004)(71190400001)(36756003)(3846002)(6116002)(53936002)(25786009)(8936002)(31696002)(68736007)(81156014)(5660300001)(229853002)(71200400001)(97736004)(66066001)(316002)(446003)(11346002)(86362001)(186003)(486006)(110136005)(476003)(54906003)(66574012)(2906002)(81166006)(478600001)(6436002)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2077; H:VI1PR0701MB2957.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: fz7zxzl+D8WWqHkyO1342noJLmaE9dZrPVbszj/3QNmH/xZeYez5hHYo6cthZx8lW25z2S4eq0J4AuVzFz7RyGqCglsvDQTUDjTkvA2U7ozUD9YIiUve0DxVU4oSLVwgaBWQe8WKkKKAzu/NK/wIRr5cLzIKZlsKkRbI4bGv5Zmp0a3UqNQCa0CxIj+b9QmC7wTMyc1dVX6nGX+s3Pl/yvpEuJQo0TD3FEpliB79lpssUnkWQ8/VNSduGtDyCaHcH/VCRhK8MduI8o/NBUbHBH8U6VtOVMnif9299arlWQE+3kHhWUeX2l8GGB60Dlij spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <97086CEB6118FF4AA884E3D5CD4AED47@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 723e1017-ef80-4acc-2c80-08d6641c5e1f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 12:37:12.2810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2077 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffebXfD4XE576Ni4SAi8y3zwyqzIjAFjb4VMqiRF13qtF2T tKBRSr6m5buFmqwoLQ2TDF8+ZLPUdJpg0yxztUQtzFVY4pLcvQp9+z3n+f//5zkPhyYVJpEP rdNnsAa9NkUlllE1Jzuygy5WM5rQup9+6g/mOonanFsgUVc0lpHqaucNUj1ndZCHRNEm0woR neO4IzpOxMsiEtgUXSZrCIk8LUuaGilA6WvKC509lRIjalcWICkNOBze9q+IC5CMVmAzAof5 BRKKZQTzVZOEUJgImCgaoFwFhUtJsLxpJIVOJQHOzlsioZhFMDjdR7mSxTgAmt5bSRd74niw 9/ySuEQknkLQVlzGZ23B1xCUtI/zWZ44D0HuyoJYsISB82opb6fwdmjpaiZcLMcHYbLPwmsU OA5GjXf566T4GHQ//cCfI+wHD56s8V4SM/DOXk8Ij8Vg6h4hBVbC/Oc1fm7AVQhGHE5CMMdD 4UIJJYgCYdhqRwL7w/CibSPID8bqC5FgnhCDqerHhiEOHEOLEqExtr7BskXRZlLLTOsGp8H1 V5/EAm+FpmIbVYrCav+bthbR67wTWjtDBIyGnEeUoPCH8kKbpJbfhQcM1NipBiRqQkqO5bjU xLA9waxBd4bj0vTBejajDa3/neftq0HPUPPXw70I00jlJlcWMRqFSJvJZaX2IqBJlae8eK+X RiFP0GZls4a0U4bzKSzXi3xpSsXInQoPjQInajPYZJZNZw2bXYKW+hiRJDb2T9HZErV3zA7L y/2MI/X3ktXCzUiI7/1z0/5TvveGXh9huMAr86b7xlqZpUMaE5h/e1vUsvzyrojqWeWBLz5L /u6XkmUN3czfE41Uo4MIH41oc96sD3/o1fLY7Vv+IKwy7qqF2Lxh7326inPQ3J8U6m6LnDma WP5xPKpLRXFJ2t0BpIHT/gMgm5C2NwMAAA== Archived-At: Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-hip-rfc4423-bis-19=3A_=28with_COMMENT=29?= 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, 17 Dec 2018 12:37:22 -0000 SGkgTWlyamEsDQoNCk9uIDUvNy8xOCAxNjo0MiwgTWlyamEgS8O8aGxld2luZCB3cm90ZToNCj4g TWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj4gZHJhZnQtaWV0Zi1oaXAtcmZjNDQyMy1iaXMtMTk6IE5vIE9iamVjdGlvbg0KPiAN Cj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+ IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaGlwLXJmYzQ0MjMtYmlzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENP TU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEEgZmV3IG1pbm9yIGhpZ2gtbGV2ZWwgY29t bWVudHMvcXVlc3Rpb25zOg0KPiANCj4gMSkgVG8gbWUgaXQgZmVlbHMgdGhhdCBzZWMgMTEgZG9l c24ndCByZWFsbHkgYmVsb25nIGluIHRoaXMgYmlzIGRvYy4gTWF5YmUgdGhhdA0KPiBpcyByYXRo ZXIgYW4gb3duIHJlcG9ydCBvciBjYW4ganVzdCBnbyBpbiB0aGUgYXBwZW5kaXg/DQoNCm9rLCBt b3ZpbmcgdGhpcyB0byBhcHBlbmRpeC4NCg0KPiAyKSBTaG91bGQgdGhpcyBkb2N1bWVudCBtYXli ZSBkaXNjdXNzIGNvbm5lY3Rpb24gbWlncmF0aW9uIGFzIHVzZWQgYnkgUVVJQyBhcw0KPiBhbiBh bHRlcm5hdGl2ZSAoYmFzZWQgb24gc2hvcnQgdGVybSBjb25uZWN0aW9uIGlkZW50aWZpZXJzIGlu c3RlYWQgb2YgY291cnNlKT8NCj4gQmFja2dyb3VuZDogdG8gcHJvdmlkZSBpZGVudGl0aWVzIGJl dHdlZW4gdHdvIGVuZHBvaW50cywgSSdkIHNheSB0aGF0IFRMUyBpcw0KPiBzdWZmaWNpZW50IG9y IGV2ZW4gdGhlIG1vcmUgYXBwcm9wcmlhdGUgc29sdXRpb24uIEhvd2V2ZXIsIHRoaXMgZG9jdW1l bnQgZG9lcw0KPiBub3QgdGFsayB2ZXJ5IG11Y2ggYWJvdXQgY2FzZXMgd2hlcmUgdGhlIGlkZW50 aWZ5IG9mIG90aGVyIElQIGhvc3RzIChub3QNCj4gZW5kcG9pbnRzKSBpcyBpbXBvcnRhbnQuIE9m dCBjb3Vyc2UgaXQgY292ZXJzIHRoZSBtb2JpbGl0eSB1c2UgY2FzZSBidXQgdGhhdA0KPiBhbHNv IHNlZW1zIGxlc3MgcmVsZXZhbnQgd2l0aCBtaWdyYXRpb24gc3VwcG9ydCBpbiBRVUlDLg0KDQpU aGVyZSBhcmUgbWFueSBwcm90b2NvbHMgdGhhdCBISVAgY291bGQgYmUgY29tcGFyZWQgYWdhaW5z dCBidXQgdGhlIFdHIA0KZGlkIG5vdCBwdXJzdWUgdG8gZG8gaXQgaW4gdGhlIGNvbnRleHQgb2Yg dGhpcyBkb2N1bWVudC4gVExTIGFuZCBRVUlDIA0KYXJlIGFwcGxpY2F0aW9uLWxheWVyIHByb3Rv Y29scyB3aGVyZWFzIEhJUCBvcGVyYXRlcyBiZXR3ZWVuIHRyYW5zcG9ydCANCmFuZCBuZXR3b3Jr IGxheWVycywgc28gSSBhbSBub3Qgc3VyZSBob3cgZmFpciBjb21wYXJpc29uIHdlIGNvdWxkIG1h a2UuIA0KQWxzbywgYXQgdGhpcyBzdGFnZSBvZiB0aGUgZHJhZnQgSSB0aGluayBpdCB3b3VsZCBi ZXR0ZXIgdG8gcmVmZXJlbmNlIA0Kc29tZSBleGlzdGluZyBwZWVyIHJldmlld2VkIHdvcmsgYnV0 IEkgZG91YnQgYW55b25lIGhhcyBkb25lIGEgDQpjb21wYXJpc29uIG9mIEhJUCBhbmQgUVVJQy4N Cg0K From nobody Wed Dec 26 17:05:17 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 D98B3127B4C for ; Wed, 26 Dec 2018 17:05:15 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 k0c_drenk_em for ; Wed, 26 Dec 2018 17:05:10 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 B5E571286D9 for ; Wed, 26 Dec 2018 17:05:09 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id p86so11741323lfg.5 for ; Wed, 26 Dec 2018 17:05:09 -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=5ZwSdV86vnaVFIRkYg5moSE7XstbdF7RG+bd2YaJJbw=; b=QwcC7DsXOQpT2SCAVu2mmuP5EzlLcltgFdj5GKDx6/nLTp66f3B+E3m2GSZOfJNOty 1nkL/H7U8jd+tm89I//sfohft1hgvYgXhOnPuUY+QF52cK9FjssrjB71NDMRfwME56n6 DfFwf+D3TwJvYUD+WPGWY3EL6igo2OMk81VPlJYYjK0IbSl1osPciNqdnssqITKpCGsM 61b8wcux923DQ/1iQTTpLZkHjiiuvK7kMUGCbVHd3PGVNvyZtFX5zJQXNeb0ci073e8c 0WxEs8+5qGe4XlLrwn/BUz4uVQkHUUq5yAJzJZp1vdGCPJ424e46NvUosM0Cu3xf3YaJ aeVg== 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=5ZwSdV86vnaVFIRkYg5moSE7XstbdF7RG+bd2YaJJbw=; b=azku6aVSvnoQd1BX8wR98kg5W9oKwwq/4hgwI7NJ94ld8IFYWNs2hYgsMfiF5UpM49 mQexxLIt5hWEX0x7p5Aiupkkx/is/wrvGCbtvUrBaFCDEldF7f5GXI+QuipLsGfu3A18 TRv5tT8kmS0WY/eZC4/gNS4nyLnK7ej3bXnec6SHJETOSrObntVB8qe7DGjSFBAASloM zgm59ZmPTU6dmJtoRbHl8mJCsfv1jyQtssvEABunjL4tqW4ydack/RwZwsC3mlEofSJ+ GF1Rc6han9AbgNUYNS/aR24Mb+i1uKC6FcnO8wfzpSb9QH4Lke1tRYtzEn/jZgecvLRF HrHA== X-Gm-Message-State: AA+aEWamOypdRl7K/Qh45QVgmSQheOZ665/HslGw3f8MnHdHYWnOZbUQ ATYHojhD7bgZzit2HSxpFvhO0BMX2oAIr5WlZfeYbQ== X-Google-Smtp-Source: AFSGD/Ue9Cza3/ku1MjGiEB1ETqIKVXnle95XdwSrU9B0m+kpmZ5umy4Gs9asGBUqtAQJBouFVsouQfahWEhVGCwmKM= X-Received: by 2002:a19:a9d2:: with SMTP id s201mr10334953lfe.154.1545872707821; Wed, 26 Dec 2018 17:05:07 -0800 (PST) MIME-Version: 1.0 References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Wed, 26 Dec 2018 17:04:27 -0800 Message-ID: To: Miika Komu Cc: The IESG , "hipsec@ietf.org" , Gonzalo Camarillo , "hip-chairs@ietf.org" , "draft-ietf-hip-native-nat-traversal@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009e3b97057df6893f" 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: Thu, 27 Dec 2018 01:05:16 -0000 --0000000000009e3b97057df6893f Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 1:37 PM Miika Komu wrote: > Hi Eric, > > apologies for the belated response, I am not working on HIP anymore, so > it has been rather difficult to find time for this. > > On 5/4/18 22:34, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-hip-native-nat-traversal-28: 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-hip-native-nat-traversal/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099 > > > > > > I am very familiar with ICE and yet I found this document extremely > > hard to follow. The problem is that it cherry-picks pieces of ICE and > > I'm just not sure that it's a complete specification when put all > > together. I have noted a number of places where I actually am not sure > > how to implement something, and fixing those will resolve this > > DISCUSS, but IMO you really should totally rewrite this document > > either (a) as a variant of ICE or (b) as an entirely new document not > > with a pile of new text and then references out to ICE sections. > > the expected receivers of the work are the implementers of RFC5770, so > the draft follows the sectioning of the RFC5770 (which has two > interoperable implementations). > > If I understood your comment right, the variant of ICE (a) would follow > the ICE document structure but then the document would not serve anymore > HIP implementers so well. What comes to option (b), I think it would > make the the document quite long if we replicated everything in the ICE > specification (and possibly from the HIP specifications) in the draft. > Yes, it would be long, because ICE is complicated. It would also be complete. As I said in my initial ballot, if you resolve the ambiguities I noted I will clear my DISCUSS, but I think that this document should really be rewritten and i would urge the AD to require it. > > S 4.6.2. > >> > >> A host may receive a connectivity check before it has received the > >> candidates from its peer. In such a case, the host MUST > immediately > >> generate a response, and then continue waiting for the > candidates. A > >> host MUST NOT select a candidate pair until it has verified the > pair > >> using a connectivity check as defined in Section 4.6.1. > > > > Are you supposed to put this on a TODO check list as with ICE? > > I believe you refer to the triggered-check queue: > > https://tools.ietf.org/html/rfc8445#section-6.1.4.1 > > I changed the text as follows: > > A host may receive a connectivity check before it has > > received the candidates from its peer. In such a case, the > > host MUST immediately generate a response by placing it in the > triggered-check queue, and then continue > waiting for the candidates. > Well, this isn't generating a response, it's queueing a response. > S 5.8. > >> > >> 5.8. RELAY_HMAC Parameter > >> > >> As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter > >> value has the TLV type 65520. It has the same semantics as > RVS_HMAC > >> [RFC8004]. > > > > What key is used for the HMAC? > > clarified this as follows: > > [..] It has the same semantics as RVS_HMAC as specified in section 4.2.1 > in [RFC8004]. Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed > with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 > in [RFC7401]), established during the relay registration procedure as > described in Section 4.1. > This seems like it might have potential for cross-protocol attacks on the key. Why is this OK> > > S 4.2. > >> deployments in order to enable it by software configuration > update if > >> needed at some point. A host SHOULD employ only a single server > for > >> gathering the candidates for a single HIP association; either one > >> server providing both Control and Data Relay Server > functionality, or > >> one Control Relay Server and also Data Relay Server if the > >> functionality is offered by another server. When the relay > service > > > > How does this interact with mult-layered NAT?> > > No different from ICE with separated STUN and TURN servers multi-layer > NAT scenarios. Should we mention something about the issues related to > some specific scenario? > Well, with multi-layered NAT, you actually want a STUN server at each level so that you minimize hairpinning. But you recommend against that here. > S 5.7. > >> | Reserved | 0 | Reserved for future extensions > | > >> | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the > | > >> | (P) bit | | Responder can use it for the rest of > the | > >> | | | base exchange, otherwise set to zero > | > >> | Locator | Variable | Locator lifetime in seconds > | > >> | Lifetime | | > | > > > > What is the purpose of this? It's not an ICE parameter. > > In HIP, locators have a maximum lifetime after which they become > deprecated (RFC8046). Should add something here? > Yes -Ekr --0000000000009e3b97057df6893f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <miika.komu@ericsson.com> wrote:
Hi = Eric,

apologies for the belated response, I am not working on HIP anymore, so it has been rather difficult to find time for this.

On 5/4/18 22:34, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-28: Discuss
>
> 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.o= rg/doc/draft-ietf-hip-native-nat-traversal/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3099<= /a>
>
>
> I am very familiar with ICE and yet I found this document extremely > hard to follow. The problem is that it cherry-picks pieces of ICE and<= br> > I'm just not sure that it's a complete specification when put = all
> together. I have noted a number of places where I actually am not sure=
> how to implement something, and fixing those will resolve this
> DISCUSS, but IMO you really should totally rewrite this document
> either (a) as a variant of ICE or (b) as an entirely new document not<= br> > with a pile of new text and then references out to ICE sections.

the expected receivers of the work are the implementers of RFC5770, so
the draft follows the sectioning of the RFC5770 (which has two
interoperable implementations).

If I understood your comment right, the variant of ICE (a) would follow the ICE document structure but then the document would not serve anymore HIP implementers so well. What comes to option (b), I think it would
make the the document quite long if we replicated everything in the ICE specification (and possibly from the HIP specifications) in the draft.
<= /blockquote>

Yes, it would be long, because ICE is compl= icated. It would also be complete.
As I said in my initial ballot= , if you resolve the ambiguities I noted I will
clear my DISCUSS,= but I think that this document should really be rewritten
and i = would urge the AD to require it.


= =C2=A0
> S 4.6.2.
>>=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0A host may receive a connectivity check = before it has received the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0candidates from its peer.=C2=A0 In such = a case, the host MUST immediately
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0generate a response, and then continue w= aiting for the candidates.=C2=A0 A
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0host MUST NOT select a candidate pair un= til it has verified the pair
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0using a connectivity check as defined in= Section 4.6.1.
>
> Are you supposed to put this on a TODO check list as with ICE?

I believe you refer to the triggered-check queue:

https://tools.ietf.org/html/rfc8445#section-6.1.4= .1

I changed the text as follows:

A host may receive a connectivity check before it has

received the candidates from its peer. In such a case, the

host MUST immediately generate a response by placing it in the
triggered-check queue, and then continue
waiting for the candidates.

Well, this = isn't generating a response, it's queueing a response.

> S 5.8.
>>=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 5.8.=C2=A0 RELAY_HMAC Parameter
>>=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0As specified in Legacy ICE-HIP [RFC5770]= , the RELAY_HMAC parameter
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0value has the TLV type 65520.=C2=A0 It h= as the same semantics as RVS_HMAC
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8004].
>
> What key is used for the HMAC?

clarified this as follows:

[..] It has the same semantics as RVS_HMAC as specified in section 4.2.1 in [RFC8004].=C2=A0 Similarly as with RVS_HMAC, also RELAY_HMAC is is keyed=
with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 in [RFC7401]), established during the relay registration procedure as
described in Section 4.1.

This seems li= ke it might have potential for cross-protocol attacks on the key. Why
=
is this OK>


> S 4.2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0deployments in order to enable it by sof= tware configuration update if
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed at some point.=C2=A0 A host SHOUL= D employ only a single server for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0gathering the candidates for a single HI= P association; either one
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0server providing both Control and Data R= elay Server functionality, or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0one Control Relay Server and also Data R= elay Server if the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0functionality is offered by another serv= er.=C2=A0 When the relay service
>
> How does this interact with mult-layered NAT?>

No different from ICE with separated STUN and TURN servers multi-layer
NAT scenarios. Should we mention something about the issues related to
some specific scenario?

Well, with mult= i-layered NAT, you actually want a STUN server at each level
so t= hat you minimize hairpinning. But you recommend against that here.


> S 5.7.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Reserved=C2=A0 | 0=C2=A0 =C2=A0 =C2=A0= =C2=A0 | Reserved for future extensions=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Preferred | 0 or 1=C2=A0 =C2=A0| Set t= o 1 for a Locator in R1 if the=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| (P) bit=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | Responder can use it for the rest of the=C2=A0 =C2=A0|<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | base exchange, otherwise set to ze= ro=C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Locator=C2=A0 =C2=A0| Variable | Locat= or lifetime in seconds=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Lifetime=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
>
> What is the purpose of this? It's not an ICE parameter.

In HIP, locators have a maximum lifetime after which they become
deprecated (RFC8046). Should add something here?

<= /div>
Yes

-Ekr

--0000000000009e3b97057df6893f--