Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 17 December 2020 17:34 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571383A0E2F; Thu, 17 Dec 2020 09:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 36omI_V11L3B; Thu, 17 Dec 2020 09:34:26 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 37E0C3A0E33; Thu, 17 Dec 2020 09:34:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PpscFo4yZ2UbGOA7jmhYHMDeoRymi7RiecECRPHRDNuPRXz4h/FLKep0UshmJIqaGZEje00sjIMgZDN4joM7vOK1V63xepJTkb2WTs5wUheflxqv/zwistRVh638reRhTfFXJ9zE1YtoN+/ZZlQ8ZZQM8sTLFMaiydbOJewmgswHIvtov7+TkFwUry0PMiYeYbjUFOVvGnud2LD/GVKiDz1NoQ3ohatDb8kXBFtGnCLnlyFARYaSF9mKFYmO100q+M3a2EuKvVFNCYGfb5eTW6vxI62Vg+C9j6UTfEVP8A8eZVm7PpNEbpwyNpHCCUVsxuUknAA5ak/dw/XvA5oyXg==
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=KjpvcITmYGSI5AEYMQmo9s7Z+LxZMGYNmgCRLvIoCcc=; b=Y+os5cpIN5j8KIGuGkhfrNhb7kW61hPAK+h+4qhLQK0MRS9BSrImwE0kH0R5Movvyb2keeGNuIZut0yK1z8+bQ9ljbxNfMESLg+f/4aL8gcVrCS3SgepDkHy9gk6EpIIzVy22g4hLrlkThYTnUGNYpkRDmTExZON5jmLaUZLRxewI6vBhcBi2A/WoUoqtVzxhiSwA8+vlY7lAtUBrjdvWG5BBtJGIy5/g+hfWmICDReYdV3n0aK6prDMYr1tZQ2gXW3j0ed9lRhmk062V12M0TiJ/z1pMCKV2PYFbRlaCl7Itz9i5BH6AkH1Vli8ksy/b855ESId47a2BOvxJSlFAw==
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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjpvcITmYGSI5AEYMQmo9s7Z+LxZMGYNmgCRLvIoCcc=; b=MH2hxJoXyVuCJQsGA6yIbGM/v8IqPQ4UOtZ7cH/TVZi+tEM1Nv1i7C44Smn2Vkss3iKS511IHPnryNSoJHRw0laAvCevMm5SLFQr2BrVofGpUr9y9uIB1/OZ1XDHardu1fjTevQUcR58pVWAoO16cB7v+z6NpfdzuHZA+l/jzSs=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4172.eurprd07.prod.outlook.com (2603:10a6:7:99::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.12; Thu, 17 Dec 2020 17:34:17 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%7]) with mapi id 15.20.3676.011; Thu, 17 Dec 2020 17:34:16 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "supjps-ietf@jpshallow.com" <supjps-ietf@jpshallow.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: "dots@ietf.org" <dots@ietf.org>, "valery@smyslov.net" <valery@smyslov.net>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "draft-ietf-dots-signal-call-home@ietf.org" <draft-ietf-dots-signal-call-home@ietf.org>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)
Thread-Index: AQHW1IEMs9vsdNy1dUKXFtQUcezc5qn7Z94AgAAI8ICAABFlgIAACniA
Date: Thu, 17 Dec 2020 17:34:16 +0000
Message-ID: <75351574777c1f8100f15474ff5c755f6334645a.camel@ericsson.com>
References: <160821536495.8335.5498062431481972966@ietfa.amsl.com> <26637_1608218552_5FDB77B8_26637_63_1_787AE7BB302AE849A7480A190F8B93303159F25D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <83fe6f11ec1cfcfd1f4c4493854c8ce6eaa542f4.camel@ericsson.com> <135d01d6d495$9b1b94e0$d152bea0$@jpshallow.com>
In-Reply-To: <135d01d6d495$9b1b94e0$d152bea0$@jpshallow.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eaed0d85-5eb7-4637-f7c5-08d8a2b1fa95
x-ms-traffictypediagnostic: HE1PR07MB4172:
x-microsoft-antispam-prvs: <HE1PR07MB41725FDA58010904F8E8730495C40@HE1PR07MB4172.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nbMYGXtiTy5ef7KF6rqqUErCDCzgnqRWE4w6vLSutmETeexYGpLIvO3py2qV4+3xMP5HRlXIsMYJgTg4qUF9TSgT8AgZ416cu2w8FLVB/5bDI+KNBzhl6kFTG+AgmVQoVdtehrlXMboB1M1W4WVjtmCaSc8tSUaESAUqdgorvsBzRuD2lpxD/z5WTgJSjCsDwr7u97JNTCRvPPQwF+SGmQCOr8tSYegozGjJ52V/MzRI36WqTgjcghkXt+MAdyLQCyHu/EUVeXYZJ7aUv15VOTdzgoTQp25cJ1JaG8pHZ/IYSjTQICTJ/JE3avcGB4FOjNDIX0ZrKdGjHnxxSiwX9ikkdpLpRREi9NG7z4RplhFluEWqFi9K92iA1Win0Hnf31Aj6HOt7bSHyMjpykAzVDmCN+MT1ELbaXY0RNA6k5lKlXUtAHSWwhsyN6uJR+PIoSpeF3tFVhZgcqgms7GerX9lrxHfLY/F5jVS68rj7zKBKIqHFJ0Ra/P2U6S1SXyPwppkZYNAcANfEP7iOmOQ/A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39860400002)(376002)(396003)(54906003)(5660300002)(71200400001)(44832011)(8936002)(64756008)(66616009)(2616005)(76116006)(66946007)(478600001)(110136005)(6506007)(66446008)(6512007)(966005)(316002)(4326008)(186003)(26005)(86362001)(83380400001)(2906002)(6486002)(66556008)(8676002)(36756003)(66476007)(4001150100001)(99936003)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?cityLzZnVFB1VHJ0Y0pWMlhiUUUzWkNwem14NHNQdU5ma2N3VkxaZldsTmlP?= =?utf-8?B?d0JOTVUweE90Vkx0UCtjeHJwdVJJTWYzOStBTnJOeXIwMVFSbVA2YjJ0ZzQv?= =?utf-8?B?d0NjNDdDWGN2aktBNXQxRG05MXhraFpRK1A1K01raVFvK25nelF2WmJEeS85?= =?utf-8?B?bC9JOE53L0xEanVJeU8wUUJHVVNyRjJid2J4eUFXclBFNjREK2dVRklYeUtw?= =?utf-8?B?NEt2SkdxVGxKeWs2V2k4cmV0M29iV1VYeVpOcHpyV1dUSWNTb3l2dWxZSDQ4?= =?utf-8?B?Z1ZVSEx2MmlGNnRzc0xpdUYwdFdlZTc1bU9YNlNmV0JuMkJnSjhrcXMvdkhw?= =?utf-8?B?eXhTVDRpaTJ5LzdMNzFKTUZUUzg3TzdBNnVUcXEvTEQxV0dzZzA0YldvcGFB?= =?utf-8?B?SEZaNTF3U2RiTm50dElBVDVXKzJ1TnErbk5pbmhIYmNhYmhUbFRIZ0dGTDJX?= =?utf-8?B?OENHMlg0SzU1UHdlOXNVOHd3a1hDZ0ZiQVNFMjJKNTg5eTNnNTZXY01yRjFD?= =?utf-8?B?djVyMDM3WHBYM3l1WnJlT3N2cW54WUNueUQyeXMrZjk4WXpnOXV3ZkxQSTVM?= =?utf-8?B?SXhlVVVIUUVURC9iUk1XMWh0UEZhdFVuNy9UOWhOQlk1RlVXTUlYM29kblVG?= =?utf-8?B?dXpYd0k3NC9qaE9BNFBFSWl6akRrYVE4REROazUxeHdzUVFtQ24vMFRualRs?= =?utf-8?B?WnBBVnZ4SEx4Vnc3WGtrTmZhcTB1bFJaRWtFaUc0eGFHcjV3N2lsQWNPaGpH?= =?utf-8?B?c3JDK0RJWjVoM1lTYmErUlE5RjIxUkJzYTJMVC9iYlBMcURlLzNCV0NHNXlx?= =?utf-8?B?clJRUlllVUg5c0s1V2grY1lDZG42b0dwckQ2MHhnRUNhVVQramhKRnFmVlc5?= =?utf-8?B?MGZQOFlRSGc4RFJ4dkhRVjF2Y0FkU0RKQ0JMRzVZcnJKdEN1V3NQS1VHd3hL?= =?utf-8?B?aFZVQ0lyTGZuNFBJdEdkVXJqaVlrZHdNa1JDYXVMdnRMSnNBNkdDSEJTZEtn?= =?utf-8?B?U01CakoraG96SkgrbGJXeVZNZ1ZFd1JBcUcxRk5IOHFXSnE1bThVeS9mRk5x?= =?utf-8?B?V0xHaUkvb3Bmayt1S3FTY1cvcnFsV0RDOGtoY216eU1DWjUrUVlKU0w2bXc2?= =?utf-8?B?RnByUGVFbmFmdzVOM09VdjcvN1FHeldjNEMxSWxobmw0RVMrMDdQbG90ODhR?= =?utf-8?B?RitzMHg2K1BhZ0N0Vitrbkl5VTVNeE8rbFNLcFFUcHVtN0x1OVdTbjNJTHQw?= =?utf-8?B?c1E0RGRFL2I1akFZbncyZ0ZUaEc3R3RZMHlKbWRuUFV4UUd2algzL2Npb3Nw?= =?utf-8?Q?V9ehtgWla0Sjgwn8JwNrfMGcax6Bcy0lg0?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-JVlufnpK0xlMWJl24U4G"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eaed0d85-5eb7-4637-f7c5-08d8a2b1fa95
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 17:34:16.8769 (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: VveTugpQ6hPhsR680sphDCDFZIYq7ERlCim37fuP9OTOYmktsS8W+s0+Cb1L0x/2dW47aolHCFt6bcDCHvQ25gwbhXsRSLmD5l6ZD/1Bum4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4172
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Cg0L9bI0KWX63NqlGh4J1yBPARo>
Subject: Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 17:34:28 -0000

Hi,

On Thu, 2020-12-17 at 16:56 +0000, supjps-ietf@jpshallow.com wrote:
> Hi Magnus,
> 
> We had considered using ALPN.
> 
> While DOTS signal channel can use TLS, given that this DOTS protocol has to be
> robust in an Distribute Denial of Service attack environment, its primary use
> will be DTLS using UDP.

To my understanding ALPN is part of the TLS mechansism that applies to both TLS
and DTLS so I don't really understand the above sentence applicability.

> 
> > Based on what you write in your email to my understanding ALPN in (D)TLS
> > would work fairly well to dispatch the secured connection to the individual
> > implementation of DOTS-signal and Dots-call home if that is needed.
> 
> When using TCP, it is relatively easy to dispatch a secured connection and
> attach it to, say a forked copy of the appropriate application or a new thread
> in the application which then does all the network i/o over that secured
> connection.
> 
> However, for UDP from an implementation perspective, I cannot see how this can
> be done so the network stack can itself steer each input packet to the
> appropriate application when the traffic arrives on the same IP and port (only
> one application can receive traffic on a specific udp port).  I welcome any
> wisdom on how to do this.

So I think there are several possible implementation paths for this. I see at
least two.

First, do a 5-tuple connect on UDP to filter that particular UDP flow, process
the DTLS handshake for this socket and then based on ALPN decide on target
process and then hand over the socket and the DTLS state to the right process. 

Secondly, is to run some type of front end dispatcher that processes the packets
and tracks all the different DTLS connection and have secure message passing
between the front end dispatcher and the different servers. But this do requie
another security model and trust relationship between the dispatcher and the
servers. 

> 
> There is also a minor concern in about exposing the protocol as 
> https://tools.ietf.org/html/rfc7301#section-5  which states
> 
>    Implementers and document editors who intend to extend the protocol
>    identifier registry by adding new protocol identifiers should
>    consider that in TLS versions 1.2 and below the client sends these
>    identifiers in the clear.  They should also consider that, for at
>    least the next decade, it is expected that browsers would normally
>    use these earlier versions of TLS in the initial ClientHello.
> 
>    Care must be taken when such identifiers may leak personally
>    identifiable information, or when such leakage may lead to profiling
>    or to leaking of sensitive information.  If any of these apply to
>    this new protocol identifier, the identifier SHOULD NOT be used in
>    TLS configurations where it would be visible in the clear, and
>    documents specifying such protocol identifiers SHOULD recommend
>    against such unsafe use.
> 
> Even though it is possible to derive things from the fact that a particular
> port being used.

I think the current security properties are basically the same between two well
know ports and one port with unencrypted ALPN. And when you move to DTLS 1.3 the
alpn extension will be encrypted and you have slightly better security as the
third party observer can't know if it is DOTS signal or DOTS call home that
being used based on the handshake.

Cheers

Magnus