Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06

David Mandelberg <david@mandelberg.org> Tue, 10 October 2017 02:46 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C113431D for <secdir@ietfa.amsl.com>; Mon, 9 Oct 2017 19:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 x9PYYMxbKPab for <secdir@ietfa.amsl.com>; Mon, 9 Oct 2017 19:46:36 -0700 (PDT)
Received: from sonic304-37.consmr.mail.gq1.yahoo.com (sonic304-37.consmr.mail.gq1.yahoo.com [98.137.68.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB4A132153 for <secdir@ietf.org>; Mon, 9 Oct 2017 19:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1507603596; bh=W1Wu5J2041JGpgRN/jql1WFvLa122yoCA88p29N0gBg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=s4RH5+CfFvykayHr0xvB+UZDs5THHWgETs2DdelxfydgC6V3t/GcNL8jDrO9Cuz60l/tQFTAjbraPCe3ITLjErGKiTuIPWZ29wj18YL5hdKgriEAN++M2tYcqFDuZBvnKbY70ZPk6sQXzHyLSypCrt8/HRJEIVD6RgUeNs/32C/MDIw+f6/T3+R2oQN4hTny19TI05QbACbJwky+debJwZo4IMz5D1j1L3DTwh2H19l5H95O4BBrbchm4FI6tYLePjL31PtglEWFg4exrfdcOuul7h/K5IoLuoVODtjjiiBqjlBzvxObzsV2EJSjBdeYArtRfC3gwIlZVQYp6eBaMg==
X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW78ePnctynOFHlxgwM yfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi_8GYhw7mO8kKafYP.HzLJe54c7.fUJRU ZC13ZSGi9qzrT5VAmXbnv76E2c95c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSK UMDysYzsJqnoZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScFJndm sdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9UhEPsoHf7ixhX1FYTomv PkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJKip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnx U65xzehm_4wjfiDaYmukzlu557pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMB T7WqVQ5LB_rJGu_k-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Oct 2017 02:46:36 +0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 10 Oct 2017 02:46:32 -0000
X-Yahoo-Newman-Id: 24816.31996.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW7 8ePnctynOFHlxgwMyfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi _8GYhw7mO8kKafYP.HzLJe54c7.fUJRUZC13ZSGi9qzrT5VAmXbnv76E2c95 c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSKUMDysYzsJqno ZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScF JndmsdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9 UhEPsoHf7ixhX1FYTomvPkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJK ip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnxU65xzehm_4wjfiDaYmukzlu5 57pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMBT7WqVQ5L B_rJGu_k-
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CA0A31C608F; Mon, 9 Oct 2017 22:46:30 -0400 (EDT)
To: bruno.decraene@orange.com
Cc: "draft-ietf-ospf-encapsulation-cap.all@ietf.org" <draft-ietf-ospf-encapsulation-cap.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Alia Atlas <akatlas@gmail.com>
References: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org> <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <5ee2e3cf-4034-f9e6-4fca-92ceb57a65c5@mandelberg.org> <11040_1505805523_59C0C4D3_11040_226_4_53C29892C857584299CBF5D05346208A4787AC94@OPEXCLILM21.corporate.adroot.infra.ftgroup> <CA+b+ERneJBn_jJgDYZ+dQbb6CaLP_3xy14w4hhBWYKHkSBHnGA@mail.gmail.com> <27250_1505808909_59C0D20D_27250_468_2_53C29892C857584299CBF5D05346208A4787AEEC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <D5E66FC2.C878E%acee@cisco.com> <b9e0dfcf-d2db-a96a-a389-41336fcd209b@mandelberg.org> <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <c5a9a4fc-ecab-b471-0cf8-a044419303c1@mandelberg.org>
Date: Mon, 09 Oct 2017 22:46:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LBuX1akYMb2dGOXjUNjwpFzc9ec>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 02:46:39 -0000

Thanks for checking, that looks good.

On 10/09/2017 11:53 AM, bruno.decraene@orange.com wrote:
> [removing the iesg to limit spamming, adding Alia (responsible AD)]
> 
> Hi David,
> 
> Sorry to come back on this draft 3 weeks after our latest email, but a 
> late comment is likely to change a sentence in the draft.
> 
> As we had discussed that sentence during your secdir review, I feel that 
> it would be honest to come back to you to report that change, even if I 
> don’t feel the change is problematic.
> 
> Proposed 2 changes are the following:
> 
> § Operation
> 
> OLD:
> 
> A tunnel MUST NOT be used if there is no route toward the IP address 
> specified in the Endpoint Sub-TLV (See <xref target="EndpointTLV"/>)
> 
> or if the route is not advertised by the router advertising this Tunnel 
> Sub-TLV.
> 
> NEW:
> 
> A tunnel MUST NOT be used if there is no route toward the IP address 
> specified in the Endpoint Sub-TLV (See <xref target="EndpointTLV"/>)
> 
> or if the route is not advertised in the same OSPF domain.
> 
> ==
> 
> The reason is that in multi-area OSPF deployments, the Tunnel Sub-TLV 
> may be flooded domain-wide while the IP prefix may not. Hence both 
> advertisements would not come from the same router.
> 
> ==
> 
> §security
> 
> OLD:  It prohibits a destination outside of the OSPF domain and also to 
> other routers within the domain.
> 
> NEW: It prohibits a destination outside of the OSPF domain.
> 
> ===
> 
> As a consequence, this slightly increases the capabilities and hence the 
> security implications. However, this still restricts the use of tunnel 
> whose destination is within the OSPF domain (i.e. not Internet wide) 
> which was your original concern. Plus IMO, assuming that an attacker can 
> control the OSPF advertisement is already a significant assumption.
> 
> ===
> 
> Bottom line, I believe the change is quite small from a security 
> standpoint, but wanted to double check with you.
> 
> Thanks,
> 
> Best regards,
> 
> --Bruno
> 
>> -----Original Message-----
> 
>  > From: David Mandelberg [mailto:david@mandelberg.org]
> 
>  > Sent: Tuesday, September 19, 2017 6:24 PM
> 
>  > To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN; Robert Raszuk
> 
>  > Cc: iesg@ietf.org; draft-ietf-ospf-encapsulation-cap.all@ietf.org; 
> secdir@ietf.org
> 
>  > Subject: Re: secdir review of draft-ietf-ospf-encapsulation-cap-06
> 
>  >
> 
>   > Looks good to me too.
> 
>  >
> 
>   > On 09/19/2017 07:01 AM, Acee Lindem (acee) wrote:
> 
>  > > Hi Bruno, Robert,
> 
>  > >
> 
>  > > Sounds good to me. One nit – replace “e.g. “ with “, e.g., “ in the
> 
>  > > added text.
> 
>  > > Thanks,
> 
>  > > Acee
> 
>  > >
> 
>  > > From: Bruno Decraene <bruno.decraene@orange.com
> 
>  > > <mailto:bruno.decraene@orange.com>>
> 
>  > > Date: Tuesday, September 19, 2017 at 4:15 AM
> 
>  > > To: Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net 
> <mailto:robert@raszuk.net%20%3cmailto:robert@raszuk.net>>>
> 
>  > > Cc: The IESG <iesg@ietf.org <mailto:iesg@ietf.org 
> <mailto:iesg@ietf.org%20%3cmailto:iesg@ietf.org>>>, David Mandelberg
> 
>  > > <david@mandelberg.org <mailto:david@mandelberg.org 
> <mailto:david@mandelberg.org%20%3cmailto:david@mandelberg.org>>>,
> 
>  > > "draft-ietf-ospf-encapsulation-cap.all@ietf.org
> 
>  > > <mailto:draft-ietf-ospf-encapsulation-cap.all@ietf.org>"
> 
>  > > <draft-ietf-ospf-encapsulation-cap.all@ietf.org
> 
>  > > <mailto:draft-ietf-ospf-encapsulation-cap.all@ietf.org>>,
> 
>  > > "secdir@ietf.org <mailto:secdir@ietf.org> 
> <mailto:secdir@ietf.org%20%3cmailto:secdir@ietf.org%3e>" <secdir@ietf.org
> 
>  > > <mailto:secdir@ietf.org>>
> 
>  > > Subject: RE: secdir review of draft-ietf-ospf-encapsulation-cap-06
> 
>  > > Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org 
> <mailto:alias-bounces@ietf.org%20%3cmailto:alias-bounces@ietf.org>>>
> 
>  > > Resent-To: Xiaohu Xu <xuxiaohu@huawei.com 
> <mailto:xuxiaohu@huawei.com 
> <mailto:xuxiaohu@huawei.com%20%3cmailto:xuxiaohu@huawei.com>>>,
> 
>  > > Bruno Decraene <bruno.decraene@orange.com
> 
>  > > <mailto:bruno.decraene@orange.com>>, Robert Raszuk <robert@raszuk.net
> 
>  > > <mailto:robert@raszuk.net>>, Luis Contreras
> 
>  > > <luismiguel.contrerasmurillo@telefonica.com
> 
>  > > <mailto:luismiguel.contrerasmurillo@telefonica.com>>, Luay Jalil
> 
>  > > <luay.jalil@verizon.com <mailto:luay.jalil@verizon.com 
> <mailto:luay.jalil@verizon.com%20%3cmailto:luay.jalil@verizon.com>>>, 
> Acee Lindem
> 
>  > > <acee@cisco.com <mailto:acee@cisco.com 
> <mailto:acee@cisco.com%20%3cmailto:acee@cisco.com>>>, <akr@cisco.com
> 
>  > > <mailto:akr@cisco.com>>, <aretana@cisco.com 
> <mailto:aretana@cisco.com 
> <mailto:aretana@cisco.com%20%3cmailto:aretana@cisco.com>>>,
> 
>  > > Deborah Brungard <db3546@att.com <mailto:db3546@att.com 
> <mailto:db3546@att.com%20%3cmailto:db3546@att.com>>>, Alia Atlas
> 
>  > > <akatlas@gmail.com <mailto:akatlas@gmail.com 
> <mailto:akatlas@gmail.com%20%3cmailto:akatlas@gmail.com>>>, Acee Lindem
> 
>  > > <acee@cisco.com <mailto:acee@cisco.com 
> <mailto:acee@cisco.com%20%3cmailto:acee@cisco.com>>>
> 
>  > > Resent-Date: Tuesday, September 19, 2017 at 4:15 AM
> 
>  > >
> 
>  > >     *From:*rraszuk@gmail.com <mailto:rraszuk@gmail.com>
> 
>  > >     [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk
> 
>  > >
> 
>  > >     Please replace AS with Administrative Domain.
> 
>  > >
> 
>  > >     [Bruno] I replaced AS with “OSPF domain” as indeed, AS is a BGP 
> term
> 
>  > >     rather than an OSPF one. And as you note, in some cases, the AS and
> 
>  > >     the IGP domain may be different. Thanks.
> 
>  > >
> 
>  > >     If I have three ASes there should be no artificial limits
> 
>  > >     prohibiting encap to my central collector.
> 
>  > >
> 
>  > >     [Bruno]
> 
>  > >
> 
>  > >     If your central collector is part of the OSPF domain of the
> 
>  > >     encapsulator, there is no problem.
> 
>  > >
> 
>  > >     Otherwise, if the route to your central collector is advertised in
> 
>  > >     OSPF by the decapsulator, there is no problem.
> 
>  > >
> 
>  > >     Otherwise, if the route to your central collector is advertised in
> 
>  > >     BGP, then draft-ietf-idr-tunnel-encaps is probably the right tool.
> 
>  > >
> 
>  > >     --Bruno
> 
>  > >
> 
>  > >     Thx
> 
>  > >
> 
>  > >     R
> 
>  > >
> 
>  > >     On Sep 19, 2017 08:18, <bruno.decraene@orange.com
> 
>  > >     <mailto:bruno.decraene@orange.com>> wrote:
> 
>  > >
> 
>  > >     > From: David Mandelberg [mailto:david@mandelberg.org 
> <mailto:david@mandelberg.org> 
> <mailto:david@mandelberg.org%20%3cmailto:david@mandelberg.org%3e>]
> 
>  > >       > Sent: Monday, September 18, 2017 9:30 PM
> 
>  > >     >
> 
>  > >       > On 09/18/2017 05:08 AM, bruno.decraene@orange.com 
> <mailto:bruno.decraene@orange.com>
> 
>  > >     <mailto:bruno.decraene@orange.com> wrote:
> 
>  > >       > >   > (c) is the one that I think is worth looking into. E.g.,
> 
>  > >     does this new
> 
>  > >       > >   > extension make it easier for an attacker to route a 
> packet
> 
>  > >     across AS
> 
>  > >       > >   > boundaries, by setting a tunnel endpoint outside of the
> 
>  > >     OSPF-routed network?
> 
>  > >       > >
> 
>  > >       > > No. The following text already prohibits even more than this:
> 
>  > >       > >
> 
>  > >       > > "  A tunnel MUST NOT be
> 
>  > >       > >        used if there is no route toward the IP address
> 
>  > >     specified in the
> 
>  > >       > >        Endpoint Sub-TLV (See <xref target="EndpointTLV"/>) or
> 
>  > >     if the route is
> 
>  > >       > >        not advertised by the router advertising this Tunnel
> 
>  > >     Sub-TLV."
> 
>  > >       > >
> 
>  > >       > > - By definition, this Tunnel Sub-TLV is advertised in OSPF
> 
>  > >     i.e. from within the AS.
> 
>  > >       > > - The text also prohibits setting a tunnel endpoint to 
> another
> 
>  > >     router within the AS.
> 
>  > >       > >
> 
>  > >       > >
> 
>  > >       > > That being said, within the AS, the point "c" still applies.
> 
>  > >       > > However, thinking twice, the probability is even more 
> limited.
> 
>  > >     Indeed, one can only advertise a
> 
>  > >       > tunnel to itself. Assuming that the third party can't control
> 
>  > >     the whole routing topology (i.e. routing
> 
>  > >       > advertisement from most core routers), it cannot control the
> 
>  > >     path followed by the tunnel. Hence it
> 
>  > >       > would need to have monitoring capabilities on specific links
> 
>  > >     that it cannot choose. (the link on
> 
>  > >       > the path to itself).
> 
>  > >       > > Plus this risk is not new, as the third party could already
> 
>  > >     advertise the destination IP address of
> 
>  > >       > the packets (or of the BGP Next-hop of the BGP route matching
> 
>  > >     the packet destination), without
> 
>  > >       > using any tunnel.
> 
>  > >       > > In conclusion, although I could be wrong, I'm not seeing such
> 
>  > >     new risk. (again, assuming that
> 
>  > >       > a third party can modify the OSPF routing is a big assumption).
> 
>  > >       > >
> 
>  > >       > > But the discussion was useful, thanks for the comments.
> 
>  > >       >
> 
>  > >       > That explanation is great, thank you. I hadn't realized the
> 
>  > >     implications
> 
>  > >       > of the paragraph you quoted, when I initially read it. I'm 
> convinced
> 
>  > >       > that there isn't a security issue here, but it would be nice to
> 
>  > >     see your
> 
>  > >       > explanation in the document itself, if it's not already 
> obvious to
> 
>  > >       > anybody who knows OSPF better than I do.
> 
>  > >
> 
>  > >     I've just added the following text in the security section of my
> 
>  > >     local version:
> 
>  > >     "We note that the last paragraph of <xref target="Operation"/>
> 
>  > >     forbid the establishment of a tunnel toward arbitrary destinations.
> 
>  > >     It prohibits a destination outside of the Autonomous System and 
> also
> 
>  > >     to other routers within the AS. This avoid that a third-party
> 
>  > >     gaining access to an OSPF router be able to send the traffic to
> 
>  > >     other destinations, for e.g. inspection purposes. "
> 
>  > >
> 
>  > >     Feel free to comment/propose other text.
> 
>  > >
> 
>  > >     Since I've just published -08 a few hours ago, I'll probably delay
> 
>  > >     the upload of this new update.
> 
>  > >
> 
>  > >     --Bruno
> 
>  > >
> 
>  > >
> 
>  > >       > --
> 
>  > >       > Freelance cyber security consultant, software developer, 
> and more
> 
>  > >       > https://david.mandelberg.org/
> 
>  > >
> 
>  > >
> 
>  > 
> _____________________________________________________________________________
> 
>  > ____________________________________________
> 
>  > >
> 
>  > >     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.
> 
>  > >
> 
>  > >
> 
>  > 
> _____________________________________________________________________________
> 
>  > ____________________________________________
> 
>  > >
> 
>  > >     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.
> 
>  > >
> 
>  >
> 
>   >
> 
>   > --
> 
>  > Freelance cyber security consultant, software developer, and more
> 
>  > https://david.mandelberg.org/
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 


-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/