Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS)

Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 11 April 2019 04:51 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0672120375; Wed, 10 Apr 2019 21:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 W1isO-sQ0JzE; Wed, 10 Apr 2019 21:51:47 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E843212027F; Wed, 10 Apr 2019 21:51:46 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5652B41713F227D7E900; Thu, 11 Apr 2019 05:51:44 +0100 (IST)
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 05:51:43 +0100
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 05:51:43 +0100
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 05:51:43 +0100
Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Thu, 11 Apr 2019 10:21:30 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-pce-stateful-pce-p2mp@ietf.org" <draft-ietf-pce-stateful-pce-p2mp@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Thread-Topic: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS)
Thread-Index: AQHU76nyCsWoE0MHi0yeSlcow6ss6aY2XksA
Date: Thu, 11 Apr 2019 04:51:30 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DA107E0@BLREML503-MBS.china.huawei.com>
References: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com>
In-Reply-To: <155490660734.22896.13528098840634992626.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/QUKrb5RQGH1mrgjQN1CYZs67Hjc>
Subject: Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 04:51:50 -0000

Hi Ramon, 

Thanks for your review. 

Here is the proposed update - 

12.  Security Considerations

   The stateful operations on P2MP TE LSPs are more CPU-intensive and
   also utilize more bandwidth on wire (in comparison to P2P TE LSPs).
   If a rogue PCC were able to request unauthorized stateful PCE
   operations then it may be able to mount a DoS attack against a PCE,
   which would disrupt the network and deny service to other PCCs.
   Similarly an attacker may flood the PCC with PCUpd messages at a rate
   that exceeds either the PCC's ability to process them or the
   network's ability to signal the changes, by either spoofing messages
   or compromising the PCE itself.

   Consequently, it is important that implementations conform to the
   relevant security requirements as listed below -

   o  As per [RFC8231], it is RECOMMENDED that these PCEP extensions
      only be activated on authenticated and encrypted sessions across
      PCEs and PCCs belonging to the same administrative authority,
      using Transport Layer Security (TLS) [RFC8253], as per the
      recommendations and best current practices in [RFC7525] (unless
      explicitly set aside in [RFC8253]).

   o  Security considerations for path computation requests and
      responses are as per [RFC8306].

   o  Security considerations for stateful operations (such as state
      report, synchronization, delegation, update, etc.) are as per
      [RFC8231].

   o  Security considerations for LSP instantiation mechanism are as per
      [RFC8231].

   o  Security considerations as stated in Section 10.1, Section 10.6,
      and Section 10.7 of [RFC5440] continue to apply.


More inline - 

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Roman Danyliw via
> Datatracker
> Sent: 10 April 2019 20:00
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org; pce@ietf.org; pce-
> chairs@ietf.org
> Subject: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-stateful-pce-
> p2mp-12: (with DISCUSS)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-stateful-pce-p2mp-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The Security Considerations section has numerous helpful and appropriate
> references.  Thanks for tracking them down.  However, explicit, additional
> text is required to help identify, de-duplicate and deconflict the
> “relevant guidance” provided by them.
> 
> (1) Per “it is important that implementations conform to the relevant
> security requirements of [RFC5440], [RFC8306] and [RFC8231], and
> [RFC8281]”:
> 
> ** [RFC8231] says “RECOMMENDED that these PCEP extensions only be
> activated on authenticated and encrypted sessions across PCEs and PCCs
> belonging to the same administrative authority, using Transport Layer
> Security (TLS) [PCEPS], as per the recommendations and best current
> practices in [RFC7525]”.  Good language.
> This draft again re-states “Securing the PCEP session using Transport
> Layer Security (TLS) [RFC8253], as per the recommendations and best
> current practices in [RFC7525], is RECOMMENDED.”  Why say that twice?  Is
> there something new there?
> 

[[Dhruv Dhody]] Used the text from RFC8231. 

> ** Per Section 10.4 of RFC5440 from 2009, IPSec is a MAY and Section 10.2
> makes
> TCP-MD5 a MUST.  The more recent (2017) RFC8306 and RFC8253 reference TLS
> and TCP-AO, no IPSec.  RFC8306 explicitly says don’t use TCP-MD5.  What is
> the RECOMMENDED approach today?
> 
> (2) Per “[s]ecuring the PCEP session using Transport Layer Security (TLS)
> [RFC8253], as per the recommendations and best current practices in
> [RFC7525], is RECOMMENDED”, how should the guidance on both of these
> drafts be synthesized?  	

[[Dhruv Dhody]] Added "(unless explicitly set aside in [RFC8253])". 

> Specifically, this sentence is unclear on whether
> the the robust TLS 1.2 requirements in Section 3.4 of RFC8253 are
> RECOMMENDED, and/or whether the Security Considerations/Section 7 of
> RFC8253, which undermine these robust requirements by saying
> administrators MAY allow the usage weak ciphersuites, apply.  

[[Dhruv Dhody]] Section 3.4 of RFC8253 says - 

       *  Negotiation of a ciphersuite providing for confidentiality is
          RECOMMENDED.

Then, Section 7 says - 

   Some TLS ciphersuites only provide integrity validation of their
   payload and provide no encryption; such ciphersuites SHOULD NOT be
   used by default.  Administrators MAY allow the usage of these
   ciphersuites after careful weighting of the risk of relevant internal
   data leakage that can occur in such a case, as explicitly stated by
   [RFC6952].

The 'MAY' in the above text is to optionally allow going against something that is 'RECOMMENDED' with a suitable guidance. In my reading that is okay. Am I missing something?  

> This
> sentence also cites RFC7525 which makes statements that weak
> (NULL) cipher suites MUST NOT be negotiated in contradiction to the
> RFC8253 Section 7 guidance.
> 
[[Dhruv Dhody]] This is taken care by "(unless explicitly set aside in [RFC8253])" in the proposed update. 

> Given the discussion of TLs, some additional treatment of TLS v1.3 is
> needed, recognizing that RFC7525 does recommend “v1.2+”
> 
[[Dhruv Dhody]] Both RFC8253 and RFC7525 say TLS1.2 or later; not sure if we need to say more in this I-D (a very specific P2MP extension). 

> Again, there is helpful guidance across all of the references.  Please
> provide more textually narrative about which specific sections apply on
> the references.
> 
> 
[[Dhruv Dhody]] See proposed text. 

If the new text needs further changes, it would be very helpful if you could include the changes you would like to see.  

Thanks for your review! 

Regards! 
Dhruv

> 
> 
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce