Cheers, Nicolas!

Mikkel Troest · ‎03-11-2016

Hi XR people.

Are there any plans to add support for arbitrary extended communities in an extended-community-set?

That would be a seriously awesome feature!

My specific use-case: Inter-AS BGP Flowspec with support for the Traffic-Redirect action.

I discussed this concept with some transit-providers, and one of their concerns was that they couldn't enforce any policies on the redirect route-targets embedded in the BGP-FS update.

If we could match arbitrary extcomms, or maybe get support for the supported BGP-FS ext-comms on XR, said concern would becom a non-issue.

Cheers!

Mikkel

P.S. Just to tease you a bit: it seems that it's possible in Junos:

community-ids identifies one or more members of the community. Each community ID consists of three components, which you specify in the following format:

type:administrator:assigned-number

type is the type of extended community and can be either the 16-bit numerical identifier of a specific BGP extended community or one of these types: ...

from http://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guidelines/policy-defining-bgp-communities-and-extended-communities-for-use-in-routing-policy-match-conditions.html

Nicolas Fevrier · ‎03-12-2016

Hi Mikkel,

trying to understand the use-case, I'm not sure I get what the ext-comm will bring here (I'm not saying it's not a great idea, just that I don't get it ;))). You want to use a specific ext-community to prove to the upstream provider that your rule is legit ? (if so, nothing prevents an "attacker" to try all possible combinations in brute-force).

We currently support RPL filtering on source and destination which prevents a customer to inject a rule for a prefix they don't own. It usually protects from any hijacking / misconfiguration error.

May be you could give me an example to help me understand the benefits ?

Thanks for your patience :)

N.

Mikkel Troest · ‎03-13-2016

Hi Nicolas,

Thanks for the reply!

Let me expand a bit on what I'm on about:

Imagine a scenario where an upstream provider supports flowspec
- not only for dropping/policing, but also for redirect or marking.

From RFC 5575 we have the following BGP-FS extcomms:

+--------+--------------------+--------------------------+
| type | extended community | encoding |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action | bitmask |
| 0x8008 | redirect | 6-byte Route Target |
| 0x8009 | traffic-marking | DSCP value |
+--------+--------------------+--------------------------+

Example: The upstream sells a tiered redirect-to-scrubbing service, where the differentiated scrubbing devices
reside in different VRFs.
Customer A has bought a service which redirects his traffic to a VRF importing the RT 65000:10
Customer B has bought a service which redirects his traffic to a VRF importing the RT 65000:11

Currently, there is no way of preventing Customer A from sending RT 65000:11 or Customer B from sending 65000:10.
Both customers could even send any other arbitrary RT, which might end up in a completely random VRF in the upstream's network.

An example with traffic-marking:
A customer can signal a re-marking to any DSCP value - even EF. This could break a network.

This could happen both with malicious intent, and with a config error from the customer.

If we could match extcomm type 0x8008 or 0x8009 (or any of the others) in an extended-community-set,
we would then have the usual tools like regexp-matching etc. on the inner value of these extended communities, and we'd then be able to ensure sane values by not accepting unacceptable RTs or DSCP values.

A bit of pseudo-RPL below to illustrate:

I've "invented" extcomm-types fs-redirect (0x8008) and fs-remarking (0x8009)

!The RT-example:
!
extcommunity-set fs-redirect Tier-A-FS-Customers
 65000:10
end-set
!
extcommunity-set fs-redirect Tier-B-FS-Customers
 65000:11
end-set
!
route-policy Tier-A-Scrubbing-FS
 if extcommunity fs-redirect matches-every Tier-A-FS-Customers then
   pass
 else
   drop
 endif
end-policy
!
route-policy Tier-B-Scrubbing-FS
 if extcommunity fs-redirect matches-every Tier-B-FS-Customers then
   pass
 else
   drop
 endif
end-policy
!

!The DSCP-example:
!
ext-community-set fs-remarking FS-Remarking-Sanity-check
 40
 41
 42
 ...
 ...
 63
end-set
!
route-policy FS-Remarking-Sanity
 if extcommunity fs-remarking matches-any FS-Remarking-Sanity-check then
   drop
 else
   pass
 endif
end-policy
!

I hope this clarifies my ramblings a bit :)

Cheers!

Mikkel

Nicolas Fevrier · ‎03-13-2016

Hi Mikkel,

Thanks for take the time to provide this long explanation. I'm very sorry, I read it carefully several times and I'm still struggling to get it :(

We do support, today, the filtering on the description part of the BGP FS rule, which seems to be (at least in my perspective) a much better protection from any hijacking attempts. If you are an SP and your customer owns 182.42.0.0/16 --> you only accept/apply the rules they push you if the source or the destination section of the description is "182.42.0.0/16 ge /32" regardless of the action (remarking, redirect, rate-limit, ...).

prefix-set ALLOW-FLOW
 182.42.0.0/24 ge 32
end-set
!
route-policy ALLOW-FLOW-POLICY
  if destination-prefix in ALLOW-FLOW then
   pass
  endif
end-policy
!
 router bgp 65117
 …
 neighbor 25.2.1.14
 remote-as 65117
 update-source GigabitEthernet0/0/0/0
 address-family ipv4 flowspec
  route-policy ALLOW-FLOW-POLICY in
!

I'm probably missing the obvious here, so I will ask other people their opinion :)

Thanks,

N.

Mikkel Troest · ‎03-13-2016

Hi Nicolas,

Let me try a shorter description in stead:

In your example, I as an SP would accept a flowspec-route if the destination-prefix is e.g. 184.42.0.10/32.

I would also implicitly accept any action my customer specified in the flowspec-route.

How would I prevent the customer from signalling a traffic-marking action setting DSCP=EF for all traffic to 184.42.0.10?

Edit: Small clarification: As the SP in this example, I would want to propagate the fs-route received from the customer to my other POI routers (possibly via RR), so the worry about the customer setting DSCP to an insane vlaue has more relevance than if the fs-route was to stay and only be enforced locally at the receiving PE.

Cheers!

Mikkel

(no worries about getting the idea - I often enough struggle to decipher my own "bright" ideas :-)

Nicolas Fevrier · ‎03-14-2016

Hi Mikkel,

Ok, I finally got your point (I'm a bit slow ;))

If I'm not convinced by the redirection use-case, the DSCP remarking one is perfectly clear and it's indeed a very interesting perspective. We only considered the risk of a customer hijacking internal traffic (or another customer traffic) but never the risk of giving too much control to the customer.

I'll add it in the phase two requirements (it will not be reflected in an IOS XR version anytime soon I'm afraid).

Thanks for sharing your thoughts, we'll make it an improvement request quickly.

BR,

n.

Mikkel Troest · ‎03-14-2016

Cheers, Nicolas!

I'd like you to consider the redirect saga for the phase 2 reqs as well, even if it's not the most compelling of the lot.

Keeping it generic, a way of doing enforcement on any of the FS-signalled actions would be cool.

Thanks for the feedback!

:-) Mikkel

Arbitrary extended communities in XR