Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 22 January 2020 03:47 UTC

Return-Path: <adrian@olddog.co.uk>
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 ACF4B120013; Tue, 21 Jan 2020 19:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ukgP-X0diPTu; Tue, 21 Jan 2020 19:47:38 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 AF0F012006D; Tue, 21 Jan 2020 19:47:37 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3lZYW027282; Wed, 22 Jan 2020 03:47:35 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B01AA22044; Wed, 22 Jan 2020 03:47:35 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 994AD22042; Wed, 22 Jan 2020 03:47:35 +0000 (GMT)
Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3lYYW030115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 03:47:34 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Alvaro Retana' <aretana.ietf@gmail.com>, 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-flags@ietf.org, 'Hariharan Ananthakrishnan' <hari@netflix.com>, pce-chairs@ietf.org, pce@ietf.org
Date: Wed, 22 Jan 2020 03:47:33 -0000
Organization: Old Dog Consulting
Message-ID: <01da01d5d0d6$ae8a5de0$0b9f19a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdXQ1qTWn+9+7OIpShWvmuWukt10jw==
Content-Language: en-gb
X-Originating-IP: 89.144.205.18
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.004
X-TM-AS-Result: No--14.452-10.0-31-10
X-imss-scan-details: No--14.452-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.004
X-TMASE-Result: 10--14.452500-10.000000
X-TMASE-MatchedRID: u6ojmU07PKzxIbpQ8BhdbMVbb3pjW5MnW6IdALvH8VOZt08TfNy6OAPo J7Ws3esJDUvdohVkx3hpfZbbi+Z+q5BuyrHhdqZBRow8EUpfIBQGQwlVHBGoP4PLx3vY4vNimAz bl8iGc5+cdt621J33V2E/2sbp740YdFwK7tfa9PyiXc/ZBk0gb6m9/6ObPjnDfkiy7TTogYaKKq iRyR19ljloO+Sln/bRPbVJ6HzoBwmnPxMLRdJX1LqImyaR0axZXhG7wCQq6N0jRiu1AuxJTJxem /bPuNblXTP38lVJTCcbct6MEzra/lSLej9yd/OAQ1Q0pbURNcF3WGzw1apvHb0rWM4nIpJrHI63 c1a6Q+aTRLghURyZbTFnz6iITdye7d/9z69JooHYeXBrcJgL5CY6ALX8FNLO/ZlT98dhI5kjCDd V372aMK/vNCEa2eMJ9fbCWAY+aqM32uiNuPEGTDdfT4zyWoZS4lzqEpaPQLXcUlQs8YFKzhT7mo X2uLUVkftWLwwvjZpFvRRCBN/HWWK3QrkHqcKM1JdCMvZkkjLy++SyyVe4twDh3PVI5YW97Ofp4 TaCvCcZsk/MbokSI7qMNUHcJro7bXr9ObTHNXP0hv/rD7WVZHhDDPvdmfh4BbJs+dLiqQYYr6ux ryRSe6Xq179Xhm/usGRzEHTW2nG/WXZS/HqJ2kY41YX/o/8Ki2QFaYS1v20qtq5d3cxkNQwWxr7 XDKH8x6AZ45/n3FYWBseuv+9+VQ7AbP5+X6eO1YpTBpHh16ndcqdkPB4oCg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/F7NVkK5lqpGRqceJ4__ciNwblBI>
Subject: Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)
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: Wed, 22 Jan 2020 03:47:40 -0000

Hi again Alvaro

A separate thread for your Comments (since your Discuss was so juicy!)

> (1) Compatibility
>
> The compatibility issue described at the end of §4 could result in all types of
> unforeseen errors or more serious issues; even considering just the one flag
> defined in rfc8281: the R flag = LSP REMOVE.  One of the incompatibility
> results could be for an rfc8231-only implementation to set the R flag (it has
> unknown functionality to the sender), and then for an rfc8281 implementation to
> receive the object and remove the LSP.  Not only could this result in
> operational issues by removing an LSP that shouldn't have been removed, but
> this action could also be considered a denial of service.
>
> This is not a new issue created by this document, but given that the latent
> compatibility issues are presented, then a more robust discussion is needed --
> I would like to see it in the Security Considerations, but using the
> Compatibility Considerations section works for me too.
>
> To be clear on my expectation.  The current text sounds tentative and even
> alarming: (paraphrasing) there's an issue that cannot be solved unless we start
> over!   It would be nice to then add some text that talks about the potential
> effects: taking an unintended action, opening the door for an attacker, etc.

You are right to summarise this as "there is an issue that can't be solved unless we start over". But this has to be caveated by "examination of existing implementations, ad understanding of how people normally implement around this type of issue means it is probably not a problem".

You are right that there is an existing security issue, and that by not publishing this document we perpetuate that issue. As the current Security section says " by defining the expected behavior of implementations, this document may improve the stability of networks and thus reduce the attack surface."

We could expand that text to explain the ways in which the stability might be improved and the attack surface reduced. I.e., we could talk more about how networks might be unstable without this "fix" and we could outline the current attack surfaces. Is that what you're looking for?

>  (2) Going back to the specification:
>
>       Flags (32 bits): This document does not define any flags.
>      Unassigned flags MUST be set to zero on transmission and MUST be
>      ignored on receipt.  Implementations that do not understand any
>      particular flag MUST ignore the flag.
>
> Aren't the two Normative sentences redundant?  The most likely reason for a
> receiver to not understand a flag is for it to not have it implemented, which
> is the same as it considering it not assigned.  Are there cases that I'm
> missing which require both statements?  Perhaps s/Unassigned/Unknown and remove
> the second sentence.

Well, I may be a pedant here, but whether a flag is assigned or not is a matter of IANA fact. Whether an implementation "considers a flag to be not assigned" (I paraphrase) is a matter for an implementation. It is possible that an implementation is aware of the IANA registration but does not support or has no awareness of the meaning of a flag.

That said, even if the statements are redundant, is it actively harmful to include both? Does it cause confusion or possibly result in broken implementations?

Best,
Adrian