Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

[Robert Raszuk <[e-mail]>]

Indeed this is the problem.

My main concern is not about use by new attributes/apps which may not fit
4k msg and which can define what to do when mismatch occurs.

My concern is on the lack of clear definition on what a BGP speaker should
do 5 hops away from the sender when it receives say Extended Community or
Large Community attributes of the size of 6k ? Maybe due to a bug or attack
or xyz ...

Sometimes it is save to drop just such attribute sometimes it is not even
considering currently shipping attributes. And regardless if the attribute
is dropped or entire update is dropped the real sender will have no clue
about it.

As far as proposing text .. one practical option I see which will allow to
introduce extended msg without risk of breaking current networks would be
to define a new BGP message type: "BGP LARGE UPDATE MSG".

You still have the same problem there of handling support between new and
old peers, but at least you are not potentially  breaking what works today
nor are introducing new attack vectors to existing deployments.

//R.




On Nov 16, 2017 14:09, "Jakob Heitz (jheitz)" <[e-mail]> wrote:

> The reason I went further than that is that with extended messages, it's
> not just about a speaker and its neighbor anymore, it's about a whole BGP
> space.
>
>
>
> We should probably go further still and say:
>
>
>
> BGP speakers that are not using features that specifically require
> extended messages MUST NOT use extended messages.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* [e-mail] [mailto:[e-mail]]
> *Sent:* Wednesday, November 15, 2017 8:03 PM
> *To:* Jakob Heitz (jheitz) <[e-mail]>; Robert Raszuk <
> [e-mail]>; Susan Hares <[e-mail]>
> *Cc:* idr wg <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* RE: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> I was thinking of something more along the lines of
> https://tools.ietf.org/html/rfc7606#section-8 e.g.
>
>
>
> § Guidance for Authors of BGP Specifications
>
>
>
>    A document that specifies a new BGP attribute that may not fit in a
> 4096-octet limit MUST provide specifics
>
>    regarding how to advertise a BGP message larger than 4096 octets to a speaker that does not support Extended Messages. In particular whether the removal of the attribute is allowed/advertised or not. Trade-offs are likely similar to the ones discussed in RFC 7606. In particular, if the
>
>    attribute in question has or may have an effect on route selection or
>
>    installation, the presumption is that removing it is unsafe unless
>
>    careful analysis proves otherwise.
>
>
>
> --
>
> “Multi-octet fields MUST be in network byte order.”
>
> Possibly a reference could be added, specifying this “network byte order”. (especially for a MUST)
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> *From:* Idr [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Thursday, November 16, 2017 3:24 AM
> *To:* Robert Raszuk; Susan Hares
> *Cc:* idr wg; [e-mail]; [e-mail]
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Good point Robert. How about adding something like:
>
>
>
> Certain features used by some BGP speakers require the use of extended
> messages.
>
> Such features are indicated with a BGP capability.
>
> If a BGP speaker sends an extended message to a second speaker, but that
> message
>
> does not use a feature that requires extended messages, then the contents
> of that
>
> message may not be distributed correctly throughout the BGP space to which
> that content is targeted.
>
> This is because while the immediate neighbor speaker may support extended
> messages, every
>
> BGP speaker within the said BGP space might not support extended messages.
>
>
>
> For example, a certain BGP feature requires the use of a large BGP
> attribute.
>
> This feature is not supported by every BGP speaker within a BGP space.
>
> BGP updates with the large attribute removed might be acceptable to
> speakers
>
> that do not support the feature, even though functionality is reduced
> without the feature.
>
> If such a BGP update is longer than 4096 octets when the
>
> large attribute is removed, then it cannot be distributed to those
> speakers.
>
>
>
> To prevent the failures outlined above, a BGP speaker SHOULD not generate
> a message
>
> that is longer than 4096 octets if a feature that requires extended
> messages is not used.
>
> Furthermore, a BGP speaker SHOULD not generate a message that cannot be
> reduced to
>
> 4096 octets or less by another speaker that needs to remove the feature
> that requires
>
> extended messages.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* Idr [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Wednesday, November 15, 2017 5:56 AM
> *To:* Susan Hares <[e-mail]>
> *Cc:* idr wg <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Hi,
>
>
>
> I am concerned with the lack of clear description of what router which
> supports extended msg should do
>
> when on one side he receives an attribute bigger then 4K and not of all
> it's peers can handle it.
>
>
>
> IMO the below statement is true but a bit too vague:
>
>
>
> "Therefore putting an attribute which can not be decomposed to 4096
> octets or less in an
>
>    Extended Message is a likely path to routing failure.
>
> ​"
>
>
>
> ​And the worst part is that the BGP speaker which in fact generated
>
> such attribute ​
>
> be it on purpose or by error will not find out that its propagation has
>
> failed one or N hops away.
>
>
>
> ​Today when one is trying to inject msg over 4K (say due to a bug) it will fail locally,
>
> generate syslog etc ... ​
>
>
>
>
>
> Any comments from authors and WG on that ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
> ​
>
>
>
> On Sun, Nov 12, 2017 at 11:47 PM, Susan Hares <[e-mail]> wrote:
>
> This begins a 2 week WG LC for draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26).  Please note this draft has at least 2 implementations.
>    Please comment on whether you feel this draft is ready for
> publication.
>
>
>
> Susan Hares
>
>
>
> PS – the request for this WG LC is at:
>
> https://www.ietf.org/mail-archive/web/idr/current/msg18801.html
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>