Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce-association-diversity-08.txt

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Mon, 26 August 2019 10:39 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D815712001E; Mon, 26 Aug 2019 03:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 wQhIiVSE2WLp; Mon, 26 Aug 2019 03:39:34 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 4D9EA120089; Mon, 26 Aug 2019 03:39:34 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id c7so14732928otp.1; Mon, 26 Aug 2019 03:39:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1hKk+YzWvooDpl/NzT17ehPbTC1QrAUdn46rQhFeBf4=; b=Dp1RzUkDIN3E83FICKM88Z82m/IDtX+Rq3N5eoAm8DoFQSQJlx9MyBvZnSyk1okPyg mJYPxpYhBcTfIJ9fbDUPHF3hcOsCONzhqHc1UfdMUWN0wnc2K3h9WdGjtWf9cEwMp+eC l6ZKXiaDers6Q3SajLx1segzpZPLEV563nsgU8Gqc72IBvlDRJiaP7NRFXTmbiSQSOhY hto/czPKjC0cCrHst1VRgR4vMRgeiaBjGDe4iHWPWdRNDqB2DFsG/Ud9GShczx1PTAzJ XpbALjeXqleSDwo0p7EguS0wrFY5vCSQBP6NyJuV83NPavxDIg+LZ/8LL/Ah/1j/G4mK aDhg==
X-Gm-Message-State: APjAAAUuA079JUPIMN7azJpLm8CpSSfUlhn36zxM6pjI8GkejxOcFO+t hyH+3hUcvmHLsuiB+UWXJqLvRrm+ip/7O2Crw9XrFM4r
X-Google-Smtp-Source: APXvYqzieGBaYiE1VnkKVc7gsayvduRM7XXV/GEudxcmZxwvDMMDNl+RqYqxS5nxsFyICPMj+Y5DKVMRDwYcPWXx9VM=
X-Received: by 2002:a9d:4717:: with SMTP id a23mr14027575otf.212.1566815973390; Mon, 26 Aug 2019 03:39:33 -0700 (PDT)
MIME-Version: 1.0
References: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com> <CAM5Nu_wq1jNmjyYrHqmpA+Reb7wkXCy2JH_XNPC9D67DSK1kNQ@mail.gmail.com>
In-Reply-To: <CAM5Nu_wq1jNmjyYrHqmpA+Reb7wkXCy2JH_XNPC9D67DSK1kNQ@mail.gmail.com>
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Mon, 26 Aug 2019 12:39:21 +0200
Message-ID: <CANK0pbYVB1fY44v9Qab+4D3FROPkHihJyrEPykwf0-8OUD1LRg@mail.gmail.com>
To: draft-ietf-pce-association-diversity.all@ietf.org
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000085bca1059102c567"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/m-gA29JH_ASezhi9KEYVfbUpDtU>
Subject: Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce-association-diversity-08.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 10:39:37 -0000

Dear Mahend

thanks for you answers. Your changes look fine to me.

Two last nits:

- in the sentence you added in section 5.6 when the T flag is set, "In case
of other PCEP message, the PCE MUST return a PCErr message with Error-Type
26".
=> PCEP message other than what? This is not crystal clear. I suggest you
clarify explicitly.

- in the sentence you added in section 5.6 when the T flag is unset, "the
PCE is allowed to relax disjointness by either applying a requested
objective function (Section 5.4) if specified.  Otherwise the PCE is
allowed to reduce the required level   of disjointness (as it deems fit)"
=> as-is, there seems to be a typo: a spurious "either". How about:

"the PCE is allowed to relax disjointness by applying a requested objective
function (Section 5.4) if specified. Otherwise, if no objective function is
specified, the PCE is allowed to reduce the required level of disjointness
as it deems fit"

Cheers

Emmanuel

On Tue, Aug 13, 2019 at 4:58 PM Mahend Negi <mahend.ietf@gmail.com> wrote:

> Hi Emmanuel,
>
> Thanks for your comments. Please see inline, do find attached reworked
> draft and version-diff for reference.
>
> On Tue, Aug 13, 2019 at 3:21 AM Emmanuel Baccelli <
> Emmanuel.Baccelli@inria.fr> wrote:
>
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review, and sometimes
>> on special request. The purpose of the review is to provide assistance to
>> the Routing ADs. For more information about the Routing Directorate, please
>> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF Last
>> Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>
>> Document: draft-ietf-pce-association-diversity-08.txt
>> Reviewer: Emmanuel Baccelli
>> Review Date: 12/08/2019
>> Intended Status: Standards Track
>>
>> Summary of comments:
>>
>>     The procotol extension is simple, and its operation is documented
>> pretty well.
>>     The document is concise, and clear from my point of view.
>>     See below a couple of remarks that could be considered prior to
>> publication.
>>
>> Major Issues:
>>
>>     No major issues found.
>>
>> Minor Issues:
>>
>>     In Section 5 (Security): If I understand correctly, dynamically
>> adding a new LSP to an existing disjoint association affects the
>> (re)computation and the (re)characterization of all LSPs in this
>> association. In this case, is it entirely obvious to me that there is no
>> specific threat using the attack vector of adding an LSP to an existing
>> association, when flag T is set?
>>
>
> When T flag is set, we would have a case of no-path for the new LSP. It
> would be good to also indicate that the new LSP could not be added into the
> association group. I have added text for this.
>
> What is the state of other LSPs in an existing association after another
>> LSP was added, which resulted in the required disjointness now fails?
>>
>
> The other LSPs would not be impacted. So as such there is no specific
> security threat with T flag. But, it would be good to add some generic
> text. Updated section -
>
> 6. Security Considerations
>
>
> This document defines one new type for association, which on itself does
> not add any new security concerns beyond those discussed in
>
> [RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, adding of
> a spurious LSP into the disjointness association group
>
> could lead to re-computation and set-up of all LSPs in the group, that
> could be used to overwhelm the PCE and the network.
>
>
> Also, as stated in [I-D.ietf-pce-association-group], much of the
> information carried in the Disjointness Association object, as per
>
> this document is not extra sensitive. It often reflects information that
> can also be derived from the LSP Database, but association
>
> provides a much easier grouping of related LSPs and messages. The
> disjointness association could provide an adversary with the
>
> opportunity to eavesdrop on the relationship between the LSPs. Thus
> securing the PCEP session using Transport Layer Security (TLS)
>
> [RFC8253], as per the recommendations and best current practices in
> [RFC7525], is RECOMMENDED.
>
>>
>
>
>> Nits:
>>
>>     In Section 3 (Motivation): In my opinion, this section might benefit
>> from being split in two: a pure motivation section, and an applicability
>> section.
>>
>
> OK
>
>>
>>     In Section 4.1: it is stated that "a PCE may be limited in the number
>> of LSPs it can take into account when computing disjointness" [...] "the
>> PCE may provide no path, a shortest path, or a constrained path based on
>> relaxing disjointness, etc.  The disjoint status is informed to the PCC."
>> Here, it would be useful to forward reference to section 4.6.
>>
>
> OK
>
>>
>>     In section 4.6: the spec seems to suppose that there exists an
>> absolute order ranking different levels of disjointness,
>> such that a PCE can simply take the decision to "reduce disjointness" to
>> the next best level.
>> I suspect that this is not always easy to rank in complex cases, if at
>> all possible.
>>
>
> Added (as it deems fit).
>
>
>> Are some more flags foreseen (tbd in section 6.2 ?) for more fine-grained
>> characterization of "relaxed disjointness" in complex cases e.g. when
>> adding an LSP to an already-large disjoint association ?
>> I assume the answer is "not really".
>>
> Your assumption is right.
>
>
>>
>> Assuming the above, without becoming too ugly, specification could be
>> more explicit about ranking levels of disjointness which relaxing decisions
>> should be made, when flag T is unset.
>>
> I think, adding "as it deems fit" is better and let implementations decide
> with protocol signalling the result.
>
>
>> Else, the spec could add a clarifying sentence on the difficulty of
>> ordering absolutely many different levels of disjointness for many LSPs, in
>> the same association.
>>
> Do you still feel this to be necessary? I am not too sure.
>
>
> Thanks!
>
>
> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>