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

Hi,

I think the more we stuff with critical information for reachability (next
hops, SIDs, labels etc ...) into optional non negotiated attributes the
more we are at risks of attack potentials and hard to detect brokeness of a
networks in various ways. This draft is nothing new .. just adds more of
such potential to such bag.

One thing is to add protocol controls to BGP attributes the other is send
what really should belong to negotiated by capabilities information for
operational correctness.

However on this draft itself I still must say that it may work only in one
very specific application which by itself is questionable (see comments on
spring list).

Cheers,
R.

On Tue, Nov 18, 2014 at 6:30 PM, <bruno.decraene@orange.com> wrote:

>  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
> 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.
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>