Re: [Hipsec] Adam Roach's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

Miika Komu <miika.komu@ericsson.com> Mon, 07 October 2019 07:13 UTC

Return-Path: <miika.komu@ericsson.com>
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 AA5D312002F; Mon, 7 Oct 2019 00:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XOgkP-KGSfu9; Mon, 7 Oct 2019 00:13:07 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150054.outbound.protection.outlook.com [40.107.15.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F2912003E; Mon, 7 Oct 2019 00:13:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dyJucR1DQdHNE3MBGNnXTeJC9/cB7onReSXceO8slSScfCDfYkUKVKd8BYlMi2oyhG/SsS8hZTLnkye3reqC1rgTVi67fqoSdYitOLhaUwy5Wd8Z3NI4qZoHh3CHjA6OFIxWFI4UiEkkrZeN0eoyKqBG3Mpjw1PQ8lpjLnTdB8iJ/kh4pjbZq2jffdF44q3u1SHuAzqzRYbq8fU7PJrRzzp01oizuW5hccGXW41KYkGFVqAKe6bcs0j5uO/7UemJGcJPuRpZQcvPy1dYP80SfWAxojPpbYUOBYCT94A8Fy+1LYgdZusa/65h1kEOfseDOwm2OicYDBqsc52VlysFAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g0sCvI2eUeFptdNFHHdBN0JqNulRLj9ZAJ/vdXc4Fcc=; b=ccbYEh3VkXWI3arusgOk6JdyDZJHs1u3Swn22WP9vtghpXvtKaGlds+IGXytRyCIGAsOBVVN2rojZctWrqznk4hdGVRUyiHcByKqThFSB71qaA1Cn0aRLzjHB0VtwkmqDTpJV4sOs/S/Qz28tsGeDRMlcXc3eFtu4xba5zvTQE3W6Gt1GXG28sC69h3+nNzfOZnR/Fti1bUIrBv8PxMHx9RhVnvnQEwXLlBs0Jt93FaLmBIeHUs+t+Rg9SsQTK6FyKK5+EjBILXqT6pr4uXxSx4j0l/M9rQPC+IjhMHWOfY+P2Jxbp8cIWj8s2Z5s05EuFV9djx73c45UL2LyqyZww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g0sCvI2eUeFptdNFHHdBN0JqNulRLj9ZAJ/vdXc4Fcc=; b=Kvhih5Zv64J9jpF0/6YIDJ+KgMLrs+x+9+wkYI0//y09xCQN3u9iB/T05NCaWYQIH848OXbzEOm/1zrd7HVKRNQVHtGfGTjPoIAGF/wkKRfEELQUJmA6Fo+RB6Lx3RNsYRhewo/t5phqVZR12gjuEQVyID6ENWPt07Td23fP1Yg=
Received: from HE1PR0702MB3786.eurprd07.prod.outlook.com (52.133.7.16) by HE1PR0702MB3788.eurprd07.prod.outlook.com (52.133.5.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Mon, 7 Oct 2019 07:13:04 +0000
Received: from HE1PR0702MB3786.eurprd07.prod.outlook.com ([fe80::6561:7ae8:969:60dd]) by HE1PR0702MB3786.eurprd07.prod.outlook.com ([fe80::6561:7ae8:969:60dd%6]) with mapi id 15.20.2347.013; Mon, 7 Oct 2019 07:13:04 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "adam@nostrum.com" <adam@nostrum.com>
CC: "hip-chairs@ietf.org" <hip-chairs@ietf.org>, "draft-ietf-hip-native-nat-traversal@ietf.org" <draft-ietf-hip-native-nat-traversal@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: Adam Roach's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Thread-Index: AQHT6CHKxJGk6D4vYUWGYDWUcPde1qdNinKAgAA+Y4CABCQ4gA==
Date: Mon, 07 Oct 2019 07:13:04 +0000
Message-ID: <c6b3396dc841058616ecff6b38646445f556ecb1.camel@ericsson.com>
References: <152593099270.10455.6602365389829924376.idtracker@ietfa.amsl.com> <83a2fbd94967cc351f30427c449b0df58f53fad6.camel@ericsson.com> <71d658f7-7d73-2bbd-75aa-ed04bec0442a@nostrum.com>
In-Reply-To: <71d658f7-7d73-2bbd-75aa-ed04bec0442a@nostrum.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 51853ccf-907c-4a32-18fe-08d74af5cbe6
x-ms-traffictypediagnostic: HE1PR0702MB3788:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0702MB3788D431FAAE1B4CE14FFB4FFC9B0@HE1PR0702MB3788.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01834E39B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(189003)(51914003)(199004)(86362001)(486006)(66066001)(44832011)(476003)(2616005)(11346002)(446003)(7736002)(305945005)(25786009)(2906002)(186003)(26005)(316002)(4326008)(99286004)(6116002)(478600001)(53546011)(6506007)(76176011)(54906003)(110136005)(3846002)(102836004)(71200400001)(71190400001)(36756003)(14444005)(256004)(14454004)(66476007)(66946007)(6512007)(50226002)(6486002)(229853002)(6246003)(6436002)(81156014)(8676002)(81166006)(8936002)(118296001)(76116006)(66556008)(64756008)(66446008)(5660300002)(2501003)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3788; H:HE1PR0702MB3786.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qok5ovQp9HlCB3afgAwHZQQrg6g345k74HVWuJIeMNbipXSKamwoJ9hDDPx1/6ziNC2Q6atJwmI0q9nI8dT5ar1ZmYHqTxR14JvIrAdH7GSd6V7sQe4YhpH8X6YfCdDJys9CFtr8NNQGd6xaXO4QjlbdHn2/9rdrqvYU2nTK2a5nja91RK2q63UO22i4SzufmRny3y4j2Z2TIDmdDX1HjNNOR2SI+zv51oJRGUd15rmdfZhx2thOwNIbneDkLL7NV8Yy/VnKhxZPXyYP0Zm8L7fbdN5VPVVSuDqb1HmdmCzA93z1FWzmx1Q/wxYOXu8TbdAGxa22H8rbhX6bYAZS1pe3ex1rQV1uuUr9Jb7UkUt3vPPHhdRySCc6OA5YYPOgF5orLkO9NJA0mD+rOCEA8JHgyPNl0tYx6R+32zWJoQc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <F137C1033AB1C34FB64A4A574317BEE2@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51853ccf-907c-4a32-18fe-08d74af5cbe6
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 07:13:04.3552 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8/zIQgtrriPRDEzkja3aDf7qqSJAChiLzfWXt3rpHjhx/bEfQPOj/z8X3PcxqUVd6+zY0eIocsgZ6AE9NBTtFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3788
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/Lx3SLQVaHI2ZKsMP8xxT27RMEn8>
Subject: Re: [Hipsec] Adam Roach's Abstain on draft-ietf-hip-native-nat-traversal-28: (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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 07:13:09 -0000

Hi,

pe, 2019-10-04 kello 10:58 -0500, Adam Roach kirjoitti:
> Thanks for the reply! I think we're getting closer to an answer
> here, 
> but I'm still quite lost on one key aspect.
> 
> 
> On 10/4/19 7:15 AM, Miika Komu wrote:
> > In the legacy HIP NAT traversal (RFC5770), we have third protocol
> > (STUN) on the same port and it does not follow RFC7401 conventions
> > because it was not designed with IPsec in mind. As a result,*all*
> > packets need to be diverted to an userland daemon in order to
> > separate
> > the STUN packets from HIP/ESP.
> 
> 
> I can't figure out why this diversion is necessary. What prevents 
> characterization of packets in kernel space?

so let's split discussion of a new kernelspace component into
subproblems below. I believe the security aspects (2) could be real a
showstopper.

1. Standardization

I believe separate separate standardization effort (RFC2367?) would be
needed since this would impact all IPsec keying daemons, not just HIP
(since they share the kernel). I am not sure how to do it because
PF_KEY API is not really meant for delivering entire STUN packets to
userland daemons.

2. Security

Some security considerations are also needed to avoid messing ESP
traffic with bogus STUN packets. Probably this can be a big mess
because STUN packets don't have as strong security measures as
IKE/HIP/etc IPsec keying daemons.

Possibly STUN message security checks needs additional inspection via
userspace daemons, which makes a kernelspace solution moot.

3. Performance overhead

The kernelspace component would have to be some kind of hook in the ESP
modules (at least in the tunnel and beet modules) that detects incoming
STUN and deliver it to userspace daemons. It would still incur some
performance overhead since all ESP packets need extra inspection
(albeit incur less overhead than with userspace diversion).

4. Other IPsec keying daemons

A new ESP extension would require extra support in all existing IPsec
keying daemons since it's a new kernel module impacting all of them. It
doesn't make sense to define just a single hack for HIP.

5. Ship the kernelspace extension as a standard Linux kernel module

Have you ever implemented a Linux kernel module and tried to get it
accepted into Linux kernel? We actually tried to get HIP control plane
into Linux networking stack and failed miserably. Then we changed plans
and struggled a couple of years with the BEET IPsec module and finally
got it into Linux kernel. It was worth the trouble but personally I'd
rather not repeat this exercise again.

6. Ship the kernelspace extension as a separate kernel module

One option is to maintain a separate kernel module like with Virtual
Box or VMware has been doing earlier. So when you install HIP software,
you need to compile a kernel module. This is ok for developers, but I
don't think normal users want to do it. And it is painful to do it
everytime you have kernel updates, so you really want to have your
stuff in Linux distributions (of which there are quite a many...)

7. Repeat the exercise with Apple and Windows

No idea what it requires.