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

[Robert Raszuk <[e-mail]>]

John,

> FS uses T,V and not T,L,V for its component types, the lengths are
implicit.

That's not completely right ... number of types in NLRI include length
(called numeric_op) :) as spec defines them as 1 or 2 bytes values.

- - -

Original 5575 treated entrie NLRI as one value, allowing it to be
propagated and when locally some match was not supported it was not applied
to the data plane - but BGP still was propagating it. Here this change is
now asking for each BGP speaker involved in FS propagation that it MUST
parse all types of the NLRI and if it does not recognize any type reset the
session.

Putting aside if this is good or bad how are we going to actually roll in
such change while keeping same capabilities ?

Say someone just upgrades the OS with FS code compliant to 5575bis and
suddenly his sessions will be going down ...

I think some of my previous comments were just based on the view ... oh yes
let's make sure we propagate valid information only .. but do we all
realize the consequences of this change ? Do we check by default if prefix
is a valid IP prefix and not part of bogons or do we need policy line to do
it for us ?

I am not saying what you proposed is bad ... but I am scared about the
consequences to now validate all types encoded as part of each FS NLRI. And
if you sent 1000 and you get 1 more with new unknown type or worse some new
draft will define new numeric_op on the existing type - and receiver will
not recognize it .. all 1000 previously advertised NLRIs are going to be
withdrawn (if sessions gets reset) ...

- - -

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.

Well I think this is a deficiency of BGP that only my directly connected
(in BGP sense) peer has a chance to know my capabilities.

But putting this aside - in any multi vendor network you will often have
discrepancy among vendors on the supported features. For FS primary use
there is no loops .. you drop and mitigate DDoS when and where you can.

If not and even if you would have a map of entire BGP network in terms of
supported match and actions - what would you propose to do ? Least common
denominator ?

Thx,
R.





On Fri, Sep 25, 2020 at 9:04 PM John Scudder <[e-mail]> wrote:

> Hi Bruno,
>
> Thanks for your comments. Some replies in line.
>
> On Sep 25, 2020, at 12:56 PM, [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. 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.
>
> 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
>