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 ?

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
> https://www.ietf.org/mailman/listinfo/idr
>