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

Mahend Negi <mahend.ietf@gmail.com> Sat, 31 August 2019 09:53 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 0B0481200A3; Sat, 31 Aug 2019 02:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tJ5lNwYK8-FW; Sat, 31 Aug 2019 02:53:32 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 A3D05120099; Sat, 31 Aug 2019 02:53:32 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id 100so9324489otn.2; Sat, 31 Aug 2019 02:53:32 -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=0PXK8UYwV8LwAMGYo1pS67PwitdQ58hZ/Dy5XA95oaI=; b=T0vFU8CTf7Rr08EUrIO4mFlyf912Sw8eYdRZ7ct8rQUqBU0H4oZ2cIe27kuE0LOSw8 h1zLVyRt7o+ckZjepSEhIDAslzMU1LxxeBkh4h4dL4NKY8OXtViUo6Bi3J38fT4W4P1J 2zzTfQ7WcX7/0+KHzeF9UmgW6hE3hmaCaDy1qih7tchmLb6tPifnuQj1/ar2+UA/YeIh UlBkHXkvX1PINXF9D0gavWe6BZIh48lVcVwPM8Jg0C4XmnTHJyqbXCKUbvQkGrhG2Zb2 DPKPSL04EvT6rACksy9Vx9/+kLbStN7JT1Fp0awt0da37lXkMZzZMwn977pour4DOksx ZtTQ==
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=0PXK8UYwV8LwAMGYo1pS67PwitdQ58hZ/Dy5XA95oaI=; b=NKeJT/gIbIEkMvfTDCXO9rFuptiBMdt7fd8fopN/NT+nGJ0fmaTxMo1WbUnqUcEpkd 6n5FENrZLqQEJp3KpdyDwvlj4PAgxHlUcNyHNixLMVORr4xoDdYMN0oGdimGLS/2qnk0 Osvr1ts7UQk+jFHym6oFi29aR6n0rk+gVA5+k6aAQ36hpd5+T6zjjQSqHW7ZkX8TPwMD HAajyxjfF1UvA2EMgjhxRruaQxslfU6Ee44eo/j2djegD3+ViZ7Uief73BZUPGNeTcgm wg5lyRrhOHbS/riOd+71DtfVxWIXgBsRG+2tnp+O/iEsDkJDpeDpFvhL21uUr0LHc8XB IKnA==
X-Gm-Message-State: APjAAAVwTPKKzquCnR1O8RRQnSKolRi7E63UMBWYCWqoal9LWgsCGWke sUpJHhEsLGt8gD7PSqsmjg0ZCP+/AK2c/E7AhAQ=
X-Google-Smtp-Source: APXvYqzBEQRmR7nFeqhfmvXyegO67SWw0bcioixZ+GtFeSaj5DmOjeTM+a5A7SCk7CqL8MFEtOkpl+iVXItXh0YXL6M=
X-Received: by 2002:a9d:6213:: with SMTP id g19mr14937717otj.257.1567245211988; Sat, 31 Aug 2019 02:53:31 -0700 (PDT)
MIME-Version: 1.0
References: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com> <CAM5Nu_wq1jNmjyYrHqmpA+Reb7wkXCy2JH_XNPC9D67DSK1kNQ@mail.gmail.com> <CANK0pbYVB1fY44v9Qab+4D3FROPkHihJyrEPykwf0-8OUD1LRg@mail.gmail.com>
In-Reply-To: <CANK0pbYVB1fY44v9Qab+4D3FROPkHihJyrEPykwf0-8OUD1LRg@mail.gmail.com>
From: Mahend Negi <mahend.ietf@gmail.com>
Date: Sat, 31 Aug 2019 15:23:20 +0530
Message-ID: <CAM5Nu_zBQQ9+j6EWG7z07V1+rmhdW9f58dLVE8EFFwrPHMHRjg@mail.gmail.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Cc: draft-ietf-pce-association-diversity.all@ietf.org, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000022f94a059166b6b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ICUBtU_LZ-Ld9X6zYVyerbXSMVw>
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: Sat, 31 Aug 2019 09:53:37 -0000

Hi Emmanuel,

Thanks for your review, updated in the new version.

FYI:
New Version:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-10
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-10

Regards,
Mahendra


On Mon, Aug 26, 2019 at 4:09 PM Emmanuel Baccelli <
Emmanuel.Baccelli@inria.fr> wrote:

> 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
>>>
>>