Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations

Hi Robert,

Please see inlined [Bruno]

Bruno

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations

Some routes may be received unlabeled (from untrusted sources) and redistributed as labeled. e.g. IPv6 → 6PE, IP --> VPN IP
How would the AS protect itself (from SID collision) from non labeled/trusted  routes received with a SID attributes, and then re-advertised as labelled?

Hi Bruno,

Doesn't the above concern is solved by the below sentence from the draft:

"The BGP Label Index attribute SHOULD only be announced with BGP Prefixes carried in a labeled address-family (SAFI value 4 or SAFI value 128)."

With this in mind how can you receive SID attribute with unlabeled route ?

[Bruno] Someone doing an “experiment” or an attack and attaching this attribute deliberately.
(also it’s only a SHOULD; implementation may have bugs)

Cheers,
R.

"   A BGP speaker receiving a BGP Label index attribute from its EBGP
   neighbor SHOULD discard the attribute unless it is configured to
   accept the attribute from the EBGP neighbor."

Is good but may not be sufficient as the above BGP speaker (ASBR) may not support this document and hence will propagate the attribute over iBGP sessions. (unless we require that all routers support this document in which case we may not need a transitive attribute, which would by itself address the problem)

One option would be to mandate that by default a BGP session/peer group/AFI remove the received SID attribute. (or at least do not honor it, but I don't see the use case to keep the attribute that we don't want to use)
 e.g. something like "To contain distribution of the BGP
   Label Index attribute beyond its intended scope of applicability,
   attribute filtering MAY be deployed."

But for _received_ routes and with :s/MAY/SHOULD.

At least the currently empty security consideration section should probably discuss this.

Thanks,
Regards.
Bruno

PS: On a side note "Segment Routing Architecture" should probably be a normative reference.

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
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.