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

[[e-mail]]

Hi John,

Thanks for your answer.
Please see two replies inline [Bruno]

From: John Scudder [mailto:[e-mail]]
Sent: Friday, September 25, 2020 9:04 PM
To: DECRAENE Bruno TGI/OLN <[e-mail]>
Cc: idr@ietf. org <[e-mail]>; [e-mail]; Hares Susan <[e-mail]>
Subject: Re: Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Bruno,

Thanks for your comments. Some replies in line.


On Sep 25, 2020, at 12:56 PM, [e-mail]<mailto:[e-mail]> wrote:

...

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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*section-8__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOnjLHVOBw$>

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.

Exactly right.


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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*section-5.3__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOmjo43yJQ$>

My reading was that since the FS document carefully says “is considered malformed” and then references Section 10, which in turn references 7606 and 4760, and since 7606 and 4760 both say “reset the session if it’s malformed” that a session reset was called for.
[Bruno]
I agree that this is a valid reading.
However my reading was that draft-ietf-idr-rfc5575bis was saying that the NLRI was semantically malformed. Then that 7606 was calling for session reset only for the malformed MP_REACH attribute or syntactically incorrect NRLI, while calling for treat as withdraw when the NLRI could be recovered and hence withdrawn.

I’m fine to be declared in the rough, but so far (assuming I’m not wrong on the below second point), I do not support the proposed change.
I also note that this action may be seen as a local decision not impacting interop. Hence if we chose to modify the text, we could allow for both, allowing both types of implementation to be compliant with the RFC.

Also reviewing https://github.com/stoffi92/rfc5575bis/issues/20 I think that the outcome of the discussion was that the NRLI should not be propagated but “throw[n] away”.
I also see a specific concluding comment from stoffi92 (Christoph Loibl, the editor of the document) specifically referring to treat-as-withdraw  “unknown flow components / NLRI that are not understood completely lead to treat-as-withdraw (and thus are not propagated) -> error handling.”



I think that is the right thing, too: FS uses T,V and not T,L,V for its component types, the lengths are implicit. So, if my parser encounters an unknown type code it is impossible for me to know how to skip over that type code. At that point, parsing breaks down.
[Bruno] I had in mind the higher level of hierarchy:

   The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
   one or more 2-tuples of the form <length, NLRI value>.  It consists
   of a 1- or 2-octet length field followed by a variable-length NLRI
   value.  The length is expressed in octets.

                     +-------------------------------+
                     |    length (0xnn or 0xfnnn)    |
                     +-------------------------------+
                     |    NLRI value   (variable)    |
                     +-------------------------------+

                Figure 1: Flow Specification NLRI for IPv4

At this level, assuming that the NLRI value is found semantically incorrect, it seems to me that one could:

-          Skip this NLRI (thanks to the ‘length’ field) and continue with the next NLRI

-          Read the ‘NLRI value’ as an opaque data, and treat this NLRI as withdraw. (In the context of the discussion, this NLRI would never had been accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore’. But I’m _not_ calling for this).
Hence it seems to me that treat-as-withdraw is technically possible.

With either ‘session reset’ or ‘treat as withdraw”, this NLRI is equally dead/withdrawn. The question is about punishing the other NLRIs from this AFI/SAFI and even all other AFI/SAFI sharing this BGP session.

I also note that RFC 7606 is opening another error handling strategy in between (called AFI/SAFI disable) but this seem out of scope of the discussion as “session reset” does not appear in draft-ietf-idr-rfc5575bis. Hence this would be about RFC 7606 interpretation. (my interpretation is that 7606 allows for both, with no preference given)



Thank you.

--Bruno


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?

It’s not, this is a deficiency in FS that I think the WG needs to address in the proposed FSv2 work.

Regards,

—John

_________________________________________________________________________________________________________________________

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.