Re: [Raw] Roman Danyliw's Discuss on draft-ietf-raw-use-cases-08: (with DISCUSS and COMMENT)

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 02 December 2022 11:15 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74C0C14CEEA for <raw@ietfa.amsl.com>; Fri, 2 Dec 2022 03:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.996
X-Spam-Level:
X-Spam-Status: No, score=-6.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
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 DX-L_TlsH31m for <raw@ietfa.amsl.com>; Fri, 2 Dec 2022 03:15:19 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93938C14CEE5 for <raw@ietf.org>; Fri, 2 Dec 2022 03:15:19 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id z24so5060670ljn.4 for <raw@ietf.org>; Fri, 02 Dec 2022 03:15:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fILcoKJY6ZVtPKAHAjc0eosbWNcYadAnaD7ri3XW8D0=; b=DPvCPuOlPCAI/k2DczZuDY75JpertemYHsRUrPpBQMIn9zo+MNEcjG4qPLuzBYCt3O FAW8q9ug9T012alX6bECQDZ/zjeizyE/07EuyidYU7203cnN6KnKTswpVybzj0mdnVTU 3FHSnXwuBSrf8pLEZ8p4vAd39rsJjgDSZ017q3YmM/qOCVtdDbWQomezhL++cQ8us6Od drdbSLiLZVcvJegBmUj6mvuc03bslZUGsBvn6zxcQSmT7iPwILq8BC08F0MI7WDDMn3w D6iYf9wJkw0hupI45eKEniThLaYx6A1Znqod2Nt73GLN9uaNF3bpDPxfyRr8GxiIw8xf G18A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fILcoKJY6ZVtPKAHAjc0eosbWNcYadAnaD7ri3XW8D0=; b=znyQcwm5fHz/OedgTuifgmogNVBI8t3Z4A6zSdLyf643hErD6TKX9iwq9CyeBmsz8/ tILz3PymEpHg8AfRHSn4csD33mM21cgXjqLVf2PgiSBBgqG7CuOeTq0GfN3eMX/50Lmy xV2KUVhgL3cVlAzzJjDhBJCOpkDv22n5/dqXIkJRsy571roZllOKECBVSnSKGZmlWcqU HNRFXQDP6anPuwRczY1KdNx7NxhfCzakYs9LiAIJL8B4MfeI97J8j2yhdoow0OvOhS/Y 3XUwqEVE0twzLXNtOp7NSeF0LgvwqJg93QvC6097jlxAHZbXnnn0x3NZux4pxirv1yeq z0Rw==
X-Gm-Message-State: ANoB5pkPsyjLwK57hg1QMnAA4+sC2q3/GEJKdKFphPZ2hwpocrzz5HEK wRlPyYQIIrtkG6+7zdb4dNhvqsPr1Zon2JqlA7tIKg==
X-Google-Smtp-Source: AA0mqf6DPVZ/Y5/XlLneOMYebt6AxFYKcvllL6MRNC0ZEigkvpuylVo2QeH0DptMetJQ9lKA+hHog5MIc75sUQBzHLE=
X-Received: by 2002:a2e:380b:0:b0:279:8590:8a28 with SMTP id f11-20020a2e380b000000b0027985908a28mr13566721lja.48.1669979717176; Fri, 02 Dec 2022 03:15:17 -0800 (PST)
MIME-Version: 1.0
References: <166870577081.63597.12770105190077863670@ietfa.amsl.com> <CALypLp8bRWwKboH1zV2Lx_Jo-iZpeAk-ygZz=3kQN2r3Ma5xiw@mail.gmail.com> <69B767CF-45FF-459A-858D-8DAFE348DA94@juniper.net>
In-Reply-To: <69B767CF-45FF-459A-858D-8DAFE348DA94@juniper.net>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 02 Dec 2022 12:15:01 +0100
Message-ID: <CALypLp9OuuJdd90mwYpTWUN2UQisLWJtni_3Ve7_XeQSQXf0Gg@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>, "draft-ietf-raw-use-cases@ietf.org" <draft-ietf-raw-use-cases@ietf.org>, "raw-chairs@ietf.org" <raw-chairs@ietf.org>, "raw@ietf.org" <raw@ietf.org>, "corinna.schmitt@unibw.de" <corinna.schmitt@unibw.de>
Content-Type: multipart/alternative; boundary="000000000000d38ff905eed67373"
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/QhgzsJAHwJcJN05FfNN51t-fArw>
Subject: Re: [Raw] Roman Danyliw's Discuss on draft-ietf-raw-use-cases-08: (with DISCUSS and COMMENT)
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2022 11:15:23 -0000

Thanks a lot John. Pretty useful summary.

We thought the approach DETNET followed for the security part was fine, but
we are happy to add some text per use case as suggested.

We are working on the next revision. Note that next week is tricky in Spain
(lot's of holidays, meaning the whole week is off for most of us), so it
might take a couple of weeks to converge and submit a new revision. Our
goal is to send it before the Xmas break. Hope this is OK.

Thanks!

Carlos

Thanks,

Carlos

On Thu, Dec 1, 2022 at 8:14 PM John Scudder <jgs@juniper.net> wrote:

> Hi All,
>
> > On Nov 29, 2022, at 5:46 PM, CARLOS JESUS BERNARDOS CANO <
> cjbc@it.uc3m.es> wrote:
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 12 states the situation accurately – “Each of the potential RAW
> > use-cases will have security considerations from both the use-specific
> > perspective.”  Where are these security and privacy considerations for
> these
> > uses cases discussed?  Are these in scope to solve for RAW?  A select
> list to
> > review would be:
> >
> > ** Section 3.*. Per the amusement park use case, what are the physical
> location
> > tracking and surveillance considerations?
> >
> > ** Section 7.*.  Per the vehicle platooning use case, what are the
> physical
> > location tracking privacy considerations?
> >
> > ** Section 8.*. Per the edge robotics use case, what are the privacy
> > considerations of the video surveillance?
> >
> > ** Section 9.*.  Per the ambulance use case, what are the security
> > considerations around exchanging health care information over a wireless
> WAN?
> >
> > A clearer distinction of what is to be addressed at the protocol level,
> and
> > what seems like an application consideration is needed.
> >
> > [Carlos] This is a good point to clarify. We have followed the same
> approach as in the DETNET use cases document (RFC 8578). The RAW use cases
> document aims at documenting different use cases of interest for RAW, and
> documenting their demands in terms of rea liability and availability. The
> document does not go into the per-use case privacy and security
> considerations of potential future RAW solutions. As of today, the RAW WG
> is not chartered to work on solutions (it might be done in RAW or DETNET).
> We believe that the specific privacy and security considerations for the
> solutions would belong to a different document. Do you think we should be
> specific about this in the document? We borrowed some text from RFC 8578 to
> be consistent with the approach that DETNET followed.
>
> We talked about this at today’s IESG telechat. I thought I would take a
> stab at summarizing the points Roman made; I’m sure he will correct me if I
> get anything wrong. It was something like this:
>
> - Agreed that this document is use cases and not solutions.
> - The document presents use cases, described in prose in a fairly abstract
> way.
> - It is appropriate to talk about security+privacy *at the same level of
> abstraction* relative to the cases presented.
> - Meaning, just a sentence or two per use case probably.
> - Take the amusement park with armband doing human tracking case. It would
> be appropriate to briefly acknowledge this creates a consideration that
> will need to be worked out as part of a solution.
>
> I would add in my own words, that in the same way use cases exist to
> provide context for working on and evaluating a solution, it’s also helpful
> to identify (though not solve) any security and privacy considerations that
> a solution will foreseeably need to address.
>
> I hope this helps,
>
> —John