Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light

2017-12-13 Thread Pier Carlo Chiodi 
On Wed, Dec 13, 2017 at 04:03:53PM +0100, Ondrej Zajicek wrote:
> Hi
> 
> Here is a patch that should fix it.

I confirm it's working as in 1.6.3 now.

Is there already a scheduled release date for the fixed version?

Thanks,

-- 
Pier Carlo Chiodi
https://pierky.com

Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light

2017-12-13 Thread Ondrej Zajicek 
On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote:
> Hello,
> 
> while I was running some tests on BIRD 2.0.0 I've noticed that the
> handling of RFC8097 extended communities is different from 1.6.3.
> 
> - when 1.6.3 is used on the route server, BIRD treats the community
>   strictly according to RFC4360:
> 
>If a route has a non-transitivity extended community, then before
>advertising the route across the Autonomous System boundary the
>community SHOULD be removed from the route.
> 
> - when 2.0.0 is used, the community is treated accordingly to
>   draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
>   client.

Hi

Here is a patch that should fix it.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
commit d807ea087f8d60e25eaef8c10168a40ca6545c57
Author: Ondrej Zajicek (work) 
Date:   Wed Dec 13 15:57:44 2017 +0100

BGP: Fix non-transitive ext communities

diff --git a/nest/a-set.c b/nest/a-set.c
index a2fb6953..048e522d 100644
--- a/nest/a-set.c
+++ b/nest/a-set.c
@@ -536,6 +536,13 @@ ec_set_sort(struct linpool *pool, struct adata *src)
   return dst;
 }
 
+void
+ec_set_sort_x(struct adata *set)
+{
+  /* Sort in place */
+  qsort(set->data, set->length / 8, 8, ec_set_cmp);
+}
+
 
 static int
 lc_set_cmp(const void *X, const void *Y)
diff --git a/nest/attrs.h b/nest/attrs.h
index f66d4f04..102f378a 100644
--- a/nest/attrs.h
+++ b/nest/attrs.h
@@ -197,4 +197,6 @@ struct adata *int_set_sort(struct linpool *pool, struct adata *src);
 struct adata *ec_set_sort(struct linpool *pool, struct adata *src);
 struct adata *lc_set_sort(struct linpool *pool, struct adata *src);
 
+void ec_set_sort_x(struct adata *set); /* Sort in place */
+
 #endif
diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c
index dea3c4a6..fdc981ca 100644
--- a/proto/bgp/attrs.c
+++ b/proto/bgp/attrs.c
@@ -550,10 +550,12 @@ bgp_decode_mp_unreach_nlri(struct bgp_parse_state *s, uint code UNUSED, uint fla
 static void
 bgp_export_ext_community(struct bgp_export_state *s, eattr *a)
 {
+  a->u.ptr = ec_set_del_nontrans(s->pool, a->u.ptr);
+
   if (a->u.ptr->length == 0)
 UNSET(a);
 
-  a->u.ptr = ec_set_sort(s->pool, a->u.ptr);
+  ec_set_sort_x(a->u.ptr);
 }
 
 static void

Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light

2017-12-12 Thread Ondrej Zajicek 
On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote:
> Hello,
> 
> while I was running some tests on BIRD 2.0.0 I've noticed that the
> handling of RFC8097 extended communities is different from 1.6.3.
> The results I get follow:
> 
> - when 1.6.3 is used on the route server, BIRD treats the community
>   strictly according to RFC4360:
> 
>If a route has a non-transitivity extended community, then before
>advertising the route across the Autonomous System boundary the
>community SHOULD be removed from the route.
> 
> - when 2.0.0 is used, the community is treated accordingly to
>   draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
>   client.

Hi

Thanks for report, this seems like a bug.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light

2017-12-12 Thread Job Snijders 
Dear all,

On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote:
> while I was running some tests on BIRD 2.0.0 I've noticed that the
> handling of RFC8097 extended communities is different from 1.6.3.
> 
> Scenario:
> - AS10 announces a route to the route server;
> - the route server adds the (0x4300, 0, 1) ext community (RFC8097);
> - AS20 receives the route;
> - clients are always both on 1.6.3.
> 
> This is the filter I'm using:
> 
> filter from_client {
>   bgp_ext_community.add((unknown 0x4300, 0, 1));
>   accept;
> }
> 
> The results I get follow:
> 
> - when 1.6.3 is used on the route server, BIRD treats the community
>   strictly according to RFC4360:
> 
>If a route has a non-transitivity extended community, then before
>advertising the route across the Autonomous System boundary the
>community SHOULD be removed from the route.

Hmm... I think it is in everyone's best interest that non-transitive BGP
extended communities are actually treated as non-transitive (like in
1.6.3). This prevents surprises.

> - when 2.0.0 is used, the community is treated accordingly to
>   draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
>   client.
> 
> Since I didn't find any reference to RFC8097/rpki-light on the web site,
> I was wondering if I missed something or if this is the expected
> behaviour.

Please note that draft-ietf-sidrops-route-server-rpki-light is still
heavily in flux, and the authors indicated that they'd move towards
using a transitive extended community and abandon the non-transitive
extended communities in the current revision of the draft.

Kind regards,

Job

BIRD 2.0.0: RFC8097 extended communities and rpki-light

2017-12-12 Thread Pier Carlo Chiodi 
Hello,

while I was running some tests on BIRD 2.0.0 I've noticed that the
handling of RFC8097 extended communities is different from 1.6.3.

Scenario:
- AS10 announces a route to the route server;
- the route server adds the (0x4300, 0, 1) ext community (RFC8097);
- AS20 receives the route;
- clients are always both on 1.6.3.

This is the filter I'm using:

filter from_client {
bgp_ext_community.add((unknown 0x4300, 0, 1));
accept;
}

The results I get follow:

- when 1.6.3 is used on the route server, BIRD treats the community
  strictly according to RFC4360:

   If a route has a non-transitivity extended community, then before
   advertising the route across the Autonomous System boundary the
   community SHOULD be removed from the route.

- when 2.0.0 is used, the community is treated accordingly to
  draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
  client.

Since I didn't find any reference to RFC8097/rpki-light on the web site,
I was wondering if I missed something or if this is the expected
behaviour.

Configs and 'show route' output attached.

Bests,

--
Pier Carlo Chiodi
https://pierky.com
router id 192.0.2.10;

log "/var/log/bird.log" all;
log syslog all;
debug protocols all;

protocol device { }

protocol static own_prefixes {
route 1.0.1.0/24 reject;
}
protocol bgp the_rs {
local as 10;
neighbor 192.0.2.2 as 999;
import all;
export all;
connect delay time 1;
connect retry time 1;
}
router id 192.0.2.20;

log "/var/log/bird.log" all;
log syslog all;
debug protocols all;

protocol device { }

protocol bgp the_rs {
local as 20;
neighbor 192.0.2.2 as 999;
import all;
export all;
connect delay time 1;
connect retry time 1;
}
With BIRD 2.0.0 on the route server:

rs$ birdcl show route all
BIRD 2.0.0 ready.
Table master4:
1.0.1.0/24   unicast [AS10 17:33:32.159] * (100) [AS10i]
via 192.0.2.10 on eth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
rs$ birdcl show route all export AS20
BIRD 2.0.0 ready.
Table master4:
1.0.1.0/24   unicast [AS10 17:33:32.159] * (100) [AS10i]
via 192.0.2.10 on eth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)

from the receiving client:

receiver$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [the_rs 17:33:32 from 192.0.2.2] * 
(100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)




With BIRD 1.6.3 on the route server:

rs$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [AS10 17:36:56] * (100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
rs$ birdcl show route all export AS20
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [AS10 17:36:56] * (100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)

from the receiving client:

receiver$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [the_rs 17:36:56 from 192.0.2.2] * 
(100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
router id 192.0.2.2;
define rs_as = 999;

log "/var/log/bird.log" all;
log syslog all;
debug protocols { states, routes, filters, interfaces, events };

protocol device {};

table master sorted;

filter from_client {
bgp_ext_community.add((unknown 0x4300, 0, 1));
accept;
}

protocol bgp AS10 {
description "AS10";

local as 999;
neighbor 192.0.2.10 as 10;
rs client;

passive on;
ttl security off;
interpret communities off;

secondary;
import keep filtered on;
import filter from_client;
export all;
}

protocol bgp AS20 {
description "AS20";

local as 999;
neighbor 192.0.2.20 as 20;
rs client;

passive on;
ttl security off;
interpret communities off;

secondary;
import keep filtered on;
import filter from_client;
export all;
}
router id 192.0.2.2;
define rs_as = 999;

log "/var/log/bird.log" all;
log syslog all;
debug protocols { states, routes, filters, interfaces, events };

protocol device {};

ipv4