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

From: <[email-masked]>
Date: Tue, 18 Nov 2014 16:54:32 +0000

Hi authors,

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?

"   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.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Nov 2014 18:08:59 +0100

>
> 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.

> 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)
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: <[email-masked]>
Date: Tue, 18 Nov 2014 17:30:46 +0000

Hi Robert,

Please see inlined [Bruno]

Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations

​Hi Bruno,

"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)."​

[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.

Thanks,
Regards.
Bruno

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Nov 2014 18:43:57 +0100

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, <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Subject:* Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00 & SP isolations
>
>
>