Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS)

mohamed.boucadair@orange.com Tue, 03 November 2020 10:10 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264D23A15E6; Tue, 3 Nov 2020 02:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 kf-ZzOzkoTjx; Tue, 3 Nov 2020 02:10:54 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260B43A15FB; Tue, 3 Nov 2020 02:10:54 -0800 (PST)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CQQXX3FWwz5vSw; Tue, 3 Nov 2020 11:10:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604398252; bh=JhVqUFtt/MrgfskXXek1Ivp1h0sBZyplsDkCfPz38Ik=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=F2jkH9H3fEnAp713FkiklPUGdF0RkJ8KaMOG/2qWX23RYgzXGcb75FSXQa4z4NjSt ZRkbsY5bJ71CsG+D6H/16diX6DaY8DjcpXdAuwA1K5jbVKDbL1b6Wm7PPMY48aPUph HRWWha6+MnqH5J7KdoWsw/GrSfV6e7qJF7pLS2AnRJt7DDnwOXWL0AO0yGuxJVMa4/ JrPK0GYldRruDdiJr9R3tLTxkfFtsPx4vHr2xl1ZGz4ftNm5Tvpmei+pQuleR1usj+ 8k5LAbtRpqCS/cqotTU1bkK3XKoHNSCC7NJdh7IwMq6FAjsCztuG8beioOJt21zBbs v5AilfZLUUDEw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4CQQXW6Gg6zBrM5; Tue, 3 Nov 2020 11:10:51 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-sfc-serviceid-header@ietf.org" <draft-ietf-sfc-serviceid-header@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS)
Thread-Index: AQHWsYYdj9aNt53qTkShksvgnpc6+am2LtXQ
Date: Tue, 3 Nov 2020 10:10:50 +0000
Message-ID: <21930_1604398252_5FA12CAB_21930_254_2_787AE7BB302AE849A7480A190F8B93303156EDDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160410933541.16179.15193989217234885583@ietfa.amsl.com> <14200_1604303437_5F9FBA4D_14200_375_1_787AE7BB302AE849A7480A190F8B93303156D2E0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20201103020743.GF39170@kduck.mit.edu>
In-Reply-To: <20201103020743.GF39170@kduck.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/Knc9goUyEjiMLWHmf0K-NbHTpC8>
Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 10:11:04 -0000

Hi Ben, 

While waiting for your full review, I drafted the following text: 

   Both Subscriber Identifier and Performance Policy Context Headers
   carry opaque data.  The structure of the identifiers conveyed in
   these Context Headers is communicated only to entitled NSH-aware
   nodes.  Nevertheless, some structures may be easily inferred from the
   headers (e.g., use of IP addresses).  The use of trivial subscriber
   identifier structures together with the presence of specific SFs in a
   service function chain (e.g., lawful intercept SF) reveal sensitive
   information to every on-path device (but also to teams managing these
   devices).  Such disclosure is a violation in many jurisdictions
   because such information should be available to very few network
   operator personnel.  Furthermore, access to subscriber data usually
   requires specific access privilege levels.  To maintain that
   protection, an SF keeping operational logs should not log the content
   of a Subscriber and Performance Policy Context Headers unless the SF
   actually uses the content of these headers for its operation.  A
   mechanism for encrypting sensitive NSH data is specified in
   [I-D.ietf-sfc-nsh-integrity].  This mechanism can be considered by
   network operators when enhanced SF-to-SF security protection of NSH
   metadata is required.

Will tweak it further. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoyé : mardi 3 novembre 2020 03:08
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>rg>; draft-ietf-sfc-serviceid-
> header@ietf.org; sfc-chairs@ietf.org; sfc@ietf.org; Greg Mirsky
> <gregimirsky@gmail.com>
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS)
> 
> Hi Med,
> 
> Thanks for helping out with the early start.
> 
> On Mon, Nov 02, 2020 at 07:50:36AM +0000,
> mohamed.boucadair@orange.com wrote:
> > Hi Ben,
> >
> > This is a fair and a good point.
> >
> > FYI, we raised this point to the WG (see Slide 7 of
> https://www.ietf.org/proceedings/104/slides/slides-104-sfc-sfc-
> chair-slides-01). Because the issue is ** not specific ** to this
> spec, the WG decided to define a solution that will apply to any TLV
> carrying sensitive data (including encryption): draft-ietf-sfc-nsh-
> integrity.
> >
> > What about making this change:
> >
> > OLD:
> >    A misbehaving node within from the SFC-enabled domain may alter
> the
> >    content of Subscriber Identifier and Performance Policy Context
> >    Headers which may lead to service disruption.  Such attack is
> not
> >    unique to the Context Headers defined in this document;
> measures
> >    discussed in [RFC8300] are to be followed.
> >
> > NEW:
> >    A misbehaving node within from the SFC-enabled domain may alter
> the
> >    content of Subscriber Identifier and Performance Policy Context
> >    Headers which may lead to service disruption.  Such attack is
> not
> >    unique to the Context Headers defined in this document;
> measures
> >    discussed in [RFC8300] are to be followed. A mechanism for SFC
> integrity
> >    is specified in [I-D.ietf-sfc-nsh-integrity].
> 
> I may well have to properly read the document to comment
> confidently, but I think this change is not along the axis I am most
> concerned about right now.  (It is a find change to make, just not
> the change I was looking for
> here.)  Specifically, it is talking about "how can I protect this
> information?" rather than "why might I need to protect this
> information?".
> I think that the statement in 8300 is saying that we ("would", at
> the time of 8300, but now "will") need to consider how (e.g.) the
> per-packet subscriber information would traverse through the SFP,
> what nodes would now have access to it (at a per-packet level) that
> did not previously, whether there are network links (yes, even
> within the trusted domain) that would now have access to the
> additional metadata, if there is other cleartext data or metadata in
> the payload that is now easily associated with the subscriber for
> social-engineering/blackmail/etc. attacks, etc.  In short, the
> considerations that someone would have to think about in order to
> decide whether nsh-integrity will be needed for their deployment.
> 
> Thanks,
> 
> Ben

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.