Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

[[e-mail]]

Hi John, all,

Thanks for the careful review.
Please see inline [Bruno]


From: Idr [mailto:[e-mail]] On Behalf Of John Scudder
Sent: Wednesday, September 23, 2020 11:15 PM
To: idr@ietf. org <[e-mail]>


Hi All,

I’m a little concerned about a change I failed to notice earlier in 5575bis. Version 17 had this paragraph in Section 4.2:


   All combinations of component types within a single NLRI are allowed,

   even if the combination makes no sense from a semantical perspective.

   If a given component type within a prefix in unknown, the prefix in

   question cannot be used for traffic filtering purposes by the

   receiver.  Since a Flow Specification has the semantics of a logical

   AND of all components, if a component is FALSE, by definition it

   cannot be applied.  However, for the purposes of BGP route

   propagation, this prefix should still be transmitted since BGP route

   distribution is independent on NLRI semantics.

Version 18 removed the paragraph. I believe it was removed because of good and reasonable concerns about the “prefix should still be transmitted” part. But, it appears we threw out the baby with the bathwater: the final version of the draft has nothing that corresponds to the underlined part. It is underspecified with respect to what should be done with unknown component types. The closest it comes is this paragraph in Section 4.2 of version 26:


   A NLRI value not encoded as specified specified here is considered

   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

But I think this falls well short of being either clear or unambiguous, because what does “as specified here” mean exactly?
[Bruno] In general, I favour interop and clear spec and IMHO, the fact that you ask the question is an indication that the text is not clear enough.
However, I would not want to mess with this document as this stage; so please see the below comments as discussions/info. Especially since I’m not familiar with FS so I may be missing something obvious.

I’d like to open a discussion of whether the WG agrees that this is a bug and if so, whether it’s concerning enough to request a last-minute patch to the document, which is currently with the RFC Editor, so it’s almost an RFC. I think the least intrusive fix would be to insert the clause “including an NLRI that contains an unknown component type”, as in:


   A NLRI value not encoded as specified here,

   including an NLRI that contains an unknown component type,

   is considered

   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

Just as a side note, “error handling according to Section 10” points us to RFCs 7606 and 4760, which end up telling us to reset the session if the NLRI is malformed.

[Bruno] Thanks for providing the full picture and hence the importance of the point.
_IMHO_, RFC 7606 calls for session reset as a ‘last’  resort error handling behaviour.
8.  Guidance for Authors of BGP Specifications
[…]
The "treat-as-withdraw" approach is generally preferred and the "session reset" approach is discouraged.
https://tools.ietf.org/html/rfc7606#section-8

Treat-as-withdraw cannot be performed when the NLRI can’t be found in the update, or the NLRI can’t be effectively withdrawn typically because the peer won’t accept it in the withdraw (e.g. and IPv4 address of 5 octets). Or (my reading) we feel that the received NLRI seem so wrong that what we read may not be what was intended to be send. IOW, there is an error in the syntax.

IHMO, RFC 7606 specifies “session reset” when the MP_REACH_NLRI attribute is malformed or the NLRI is syntactically incorrect.

I’m not familiar with FS, but so far, I don’t feel that an unknown component type in FS:
- prevents the “treat-as-withdraw” approach.
- matches the RFC 7606 description of a syntactically incorrect NLRI field https://tools.ietf.org/html/rfc7606#section-5.3

Also, I don’t see capability negotiation so how is the sender supposed to know the list of component types which is supported by the receiver?

Finally, I’d like to also point to another text from RFC 7606, which I think is relevant for this rfc5575bis discussion.
8.  Guidance for Authors of BGP Specifications
[…]
   Authors
   of BGP documents are also reminded to review the discussion of
   optional transitive attributes in the first paragraph of the
   Introduction of this document.
https://tools.ietf.org/html/rfc7606#section-8

Thanks,
--Bruno

Until we get a chance to discuss this, I’ve sent a note to the RFC Editor asking them to hold publication.

Thanks,

—John

P.S.: The version 26 text also has a proofreading error, “specified specified”. But I assume the RFC Editor would fix that anyway.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.