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

Mahend Negi <mahend.ietf@gmail.com> Tue, 13 August 2019 14:58 UTC

Return-Path: <mahend.ietf@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 6D2E5120130; Tue, 13 Aug 2019 07:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.587
X-Spam-Level:
X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VG7SMUXXojmS; Tue, 13 Aug 2019 07:58:50 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 75DA1120251; Tue, 13 Aug 2019 07:58:50 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id g17so22622485otl.2; Tue, 13 Aug 2019 07:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/fDeDH37Pp/RKg/X1sjb3ruOoI4XwxYGjXoQpwif7g=; b=Kd94uieHbXElHN9Ew6iSUz/eUmSuCDg6I6c9vOgtlrX+j0gyA17gbIDQWfNB+XYPnE n3O1pLNm3YSIbv0aSaULma3U/3aI8yxSDlODo3xhCpHayrjUxKry1iFbcZ32iIlR4ych RBT/Nf6NxZc++aXw1aT86Cj+xRC6sObwqveWcaCJZmfvkbO9hZVD/4DNCHn+WXu8hKeK 18vJKWKFMxIlvPJg2X2KaMFvrAGG54RyXnV7YOzuZrRcan4brIpNlo5mCvvLP35pwEmq ZxtKXeCRTPwfWCD2t9SP7sLUdLWZzXElb6YVgmDyGr3IOzfEQVk6pNDvSG/nZaK1FU6Q Z/Zw==
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=G/fDeDH37Pp/RKg/X1sjb3ruOoI4XwxYGjXoQpwif7g=; b=nfsURVntL7G24Nzr8UJ49kOcY09xuAP797gR2xFe+kwXOI7LtGpgnXzmX2Fwx9jgGO jOEs0o9yJWozZWX49DK9mxtgep+M1aWAJj5LPjRb/DXq3/clUHVjU41BmnTbn9pRL+11 kPkiFBolk1JGedU8ogjAiYXq9Lp6vufQpkCrar8XFGI8zMLczkhnzPMppZAYlg4iDvcL YL1lXPfIevMqUgvsHh2ooC4O8ifMQsUYVA5M5/PBoXAS2So22Kvzb3YTRri9quLghH8x IIXIP9X28vffA9k0q7LVpPeo7MNunWUkwmkfkRFkTnfuKaE1vvZjIIfXouMwZXGpATfv l2Cw==
X-Gm-Message-State: APjAAAXhTs7GP76b7vQsgQhZf1w1MRetfuMa6qG7ceUHEwS9YAv0bjbN 7FdFbxPp9GMeLhdYrT03/f/XvZyxiGwdUXzIWqw=
X-Google-Smtp-Source: APXvYqwn+nwbrAAKHAHyfzkMh78A2B/bapieVwdJuTK9FqOQUzjvjWvgxcqReYQwyqnpvnDjTRPbxQNmJ7ZfXpdKHFk=
X-Received: by 2002:aca:4256:: with SMTP id p83mr1848808oia.125.1565708329579; Tue, 13 Aug 2019 07:58:49 -0700 (PDT)
MIME-Version: 1.0
References: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com>
In-Reply-To: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com>
From: Mahend Negi <mahend.ietf@gmail.com>
Date: Tue, 13 Aug 2019 20:28:38 +0530
Message-ID: <CAM5Nu_wq1jNmjyYrHqmpA+Reb7wkXCy2JH_XNPC9D67DSK1kNQ@mail.gmail.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, pce@ietf.org, draft-ietf-pce-association-diversity.all@ietf.org
Content-Type: multipart/mixed; boundary="000000000000cef74d059000e000"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/7WW57Ppe03wpmwIYXlF1sSC9cJc>
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: Tue, 13 Aug 2019 14:59:00 -0000

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
>