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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jan 2020 03:47:33 -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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 22 Jan 2020 13:02:21 -0800

On January 21, 2020 at 10:47:36 PM, Adrian Farrel wrote:

Adrian:

Hi!

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

Yes, that would be good.

Thanks!!

Alvaro.