Re: [ippm] Tsvart early review of draft-ietf-ippm-ioam-direct-export-06

Colin Perkins <csp@csperkins.org> Fri, 26 November 2021 13:40 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B9D3A0443; Fri, 26 Nov 2021 05:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX3iIquzaolk; Fri, 26 Nov 2021 05:40:43 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65B53A0433; Fri, 26 Nov 2021 05:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=CX1dqs/qK3e75QJQ0NsSgVfgOHaH0vTqhRiBezD9Fdk=; b=hkT2nPiUMTBivQJm+/y2QSC8/a Ai60fOr+jT8aqHy+91LrulyMluOA72MHTKHC8K/E+DOe3uQ9rgkp40j11wKaqjBOlVwJj6giumR6P Hn4oVf1sfEXBtAYVM6qiok1gTXwXsYSL255PMWV/YmTBkExZbRLBFfzO+1LoKP9eYOJqMh7aJhpfi QJ25A/obiWuZjjhOSHKVVJJAG7lRuGjXVihETqcci11DKcE8I5ZOgReHIe6b04VXmNSN+uSY4zKow R+dG5NcHSf8ChyTKJwp1WVFdNxr85egOb6l9jI7V9tseGJXEebFrU3zEKSz/geO8AM0sU0WUhYRtR U2Nyq+Eg==;
Received: from [81.187.2.149] (port=47797 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1mqbSx-0008Lx-ON; Fri, 26 Nov 2021 13:40:39 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CABUE3XkLEN8k5-t33UAPXiViOBWSs6NEZkPutVkESoWKb8ifXw@mail.gmail.com>
Date: Fri, 26 Nov 2021 13:40:29 +0000
Cc: IPPM Chairs <ippm-chairs@ietf.org>, tsv-art@ietf.org, draft-ietf-ippm-ioam-direct-export.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <77C2CDAF-5911-4EF8-B841-A7B98653BA77@csperkins.org>
References: <163068085282.8497.2281892161766368778@ietfa.amsl.com> <CABUE3XkLEN8k5-t33UAPXiViOBWSs6NEZkPutVkESoWKb8ifXw@mail.gmail.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 19
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/mfZIRXmWtTS0Rs0f8ZpabB78tZg>
Subject: Re: [ippm] Tsvart early review of draft-ietf-ippm-ioam-direct-export-06
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Nov 2021 13:40:49 -0000

Hi,

Apologies – I realise I’m replying to this very late.

> On 4 Oct 2021, at 08:13, Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
> 
> Dear Colin,
> 
> Thanks for the feedback.
> 
> Please see below a comment and a question regarding your feedback.
> 
> 
> On Fri, Sep 3, 2021 at 5:54 PM Colin Perkins via Datatracker
> <noreply@ietf.org> wrote:
> [snip]
> 
>> It may be worth considering to require the exporting mechanism to perform an
>> authenticated handshake with the destination to which it will export data, to
>> gain explicit consent to export the data to that destination, before starting
>> to send exported data.
> 
> [TM] The point is well-taken. The following text edit is proposed,
> borrowing some of the text from your comment:
> OLD:
>   Although the exporting method is not within the scope of this
>   document, any exporting method MUST secure the exported data from the
>   IOAM node to the receiving entity.  Specifically, an IOAM node that
>   performs DEX exporting MUST send the exported data to a pre-
>   configured trusted receiving entity.
> NEW:
>   Although the exporting method is not within the scope of this
>   document, any exporting method MUST secure the exported data from the
>   IOAM node to the receiving entity.  Specifically, an IOAM node that
>   performs DEX exporting MUST send the exported data to a pre-
>   configured trusted receiving entity. Furthermore, an IOAM node
>   MUST gain explicit consent to export data to a receiving entity before
>   starting to send exported data.

Something like that would seem appropriate. 

>> It may also be worth considering to add authentication
>> of IOAM DEX triggers, to ensure they come from a known and trusted source,
>> before acting on export requests.
>> 
> 
> [TM] Can you please clarify what you mean by "add authentication of
> IOAM DEX triggers"? What is the threat that you have in mind?


As the security considerations section notes, there’s a risk that an attackers could inject a spoof packet containing an export trigger. One way to prevent that would be to use a digital signature to authenticate the trigger messages as being from an authorised source. Maybe the larger IOAM framework already includes this, or a discussion of why it’s not appropriate, in which case it’s sufficient to add a (clearer) reference to that discussion. But if not, then the draft could usefully either add that, or add some discussion about why it’s not needed/appropriate. 

-- 
Colin Perkins
https://csperkins.org/