Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-probe-attribution-05

Justin Iurman <justin.iurman@uliege.be> Thu, 08 June 2023 20:28 UTC

Return-Path: <justin.iurman@uliege.be>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23471C151545; Thu, 8 Jun 2023 13:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.395
X-Spam-Level:
X-Spam-Status: No, score=-4.395 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uliege.be
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3AehpBkKl0g; Thu, 8 Jun 2023 13:28:17 -0700 (PDT)
Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FEFC151089; Thu, 8 Jun 2023 13:28:08 -0700 (PDT)
Received: from [192.168.1.62] (125.179-65-87.adsl-dyn.isp.belgacom.be [87.65.179.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by serv108.segi.ulg.ac.be (Postfix) with ESMTPSA id DBB88200C014; Thu, 8 Jun 2023 22:28:03 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 serv108.segi.ulg.ac.be DBB88200C014
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uliege.be; s=ulg20190529; t=1686256084; bh=zHJUaIiM6eyoBPEZZglEC67+VwIZEV7JClQpJ4zAdn4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=UAQAmDLApmVvv1wmusV21RRwoCrsi/jLgzTW3biySaviHbw15NK0L2s0yBJL6+GVq 2oQrJ3ysWWcfEtIc5Ce8AwfQe9+fzsBTEVCE8pV45KQKLaTncMYeOZIw8pHqGua6TQ DOIvlG7CxAX2aVWvLfoP37GGgtbDR1RkUoUbo7czQfyTiACU1lDMPPIZGYOT2FKK/o xJsuGPaTMgMxbX/7A1KFvValUhJ7O9FRPaUVKtRnblg21xXcDBw0mL+++8Yud8c62r I/chiO/S8UjXNRiXYTwO2/zojm4T2wyjjpJ9zkPk9aHtLq8K4nHIlmbm7dZiXwI9vW NtMSQrY5Cx9WQ==
Message-ID: <c03e5515-904b-d746-f512-8dd985991b6e@uliege.be>
Date: Thu, 08 Jun 2023 22:28:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: Linda Dunbar <linda.dunbar@futurewei.com>, ops-dir@ietf.org
Cc: draft-ietf-opsec-probe-attribution.all@ietf.org, last-call@ietf.org, opsec@ietf.org
References: <168624040559.34152.16732715656841514502@ietfa.amsl.com>
From: Justin Iurman <justin.iurman@uliege.be>
In-Reply-To: <168624040559.34152.16732715656841514502@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/cpK9ZzhEXsEzaWIPg7m_nAnVo_o>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-probe-attribution-05
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2023 20:28:23 -0000

Hi Linda,

Please see inline ([JI]).

On 6/8/23 18:06, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Not Ready
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last-call comments.
> 
> Summary:
> This document describes the method for any organizations to send queries to
> understand the received unsolicited probing packets.

[JI] I think there might be a misunderstanding here. What we define for 
the in-band technique is just a simple way to include a probe 
description URI (a link, an email address, a phone number, etc) in 
probes/packets so that third parties on the path would be able to 
identify them (what's the reason for such probes? who's responsible for 
that? what's the purpose? etc). We do *not* define how third parties 
would verify the probe attribution (at least, we explain how, but we do 
not define a query to do that automatically).

> Issues:
> - Are those queries generated automatically?

[JI] Not really sure about what you mean with "queries". See the above 
explanation. If I missed your point, please shout.

> - If the queries are generated automatically, does it require routers upgrade
> to support the auto-generating of those queries? - If the queries are generated
> manually, the draft should give some detailed examples since those queries will
> be generated by people not coming to IETF. - Today, most routers ignore the
> Internet probes they don't support. What are the problems of ignoring them?

[JI] No, routers do not need any upgrade. If the out-of-band technique, 
nothing is included in probes. If the in-band technique, the probe 
attribution is included in probes, but these bytes are just like data 
payload.

Thanks,
Justin

> Best Regards,
> Linda Dunbar
> 
> 
>