Re: Large communities indicating RPKI VALID status

[Job Snijders via Bird-users]

On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users <
bird-users@network.cz> wrote:

> Hi there Richard,
>
> On 4/29/24 19:14, Richard Laager wrote:
>
> Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge 
> and simply reject INVALID routes.
>
> Why would one want to accept INVALID at all?
>
> If we agree one would reject INVALID, then what is left to tag?
>
> For my specific use case I wanted to add a community for VALID and
> UNKNOWN. I'm going to look into the non-transitive extended communities to
> see how this works out.
>


Sure, but why add such communities? It reduces performance and doesn’t add
security benefits.

OTOH - it can satisfy curiosity about where traffic is flowing - then
again, using a traffic analyser like pmacct or Kentik helps offer insight
how much traffic is going to Valid vs Not-Found destinations, without the
need to add any communities.

I’m not saying you shouldn’t pursue adding a few non-transitive extended
communities here and there for your use case; just that generally speaking,
operators probably should not apply different policies for Valid and
Not-Found states.

Kind regards,

Job

>

Re: Large communities indicating RPKI VALID status

[Job Snijders via Bird-users]

On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
> On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> > There's internet draft describing in detail, why it's not a good idea to
> > store RPKI validation state inside community variables at all..
> > 
> > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html
> 
> Well, note that this draft is primarily about not announcing validation
> state in transitive attributes to the whole internet.

Yes

> But there are good reasons for having validation state in
> non-transitive BGP attributes (or communities properly filtered out on
> AS egress). Validating RPKI and marking routes at AS ingress ensures
> that all routers within AS have consistent routing state and thus
> avoiding routing loops.

Perhaps I am missing something, but how does marking in itself help
avoid routing loops?

I am under the impression that a requirement for intra-AS transitive
marking follows from non-standard modifying of non-transitive local
attributes (for example, 'weight' or 'preference') based on the
validation state - which is not what I'd recommend to begin with.

Merely rejecting RPKI-invalid routes at the AS ingress and *not*
manipulating any other local or transitive path attributes will also
ensure a consistent routing state.

> Unfortunately large communities do not have transitive flag like
> extended ones
> so perhaps it would make sense to use extended community for this
> purpose. Or perhaps there should be well-known extended community for
> that ...

https://www.rfc-editor.org/rfc/rfc8097.html ?

Kind regards,

Job

Re: [patch] add 'source address' configuration option to RPKI protocols

[Job Snijders via Bird-users]

On Thu, Feb 22, 2024 at 03:17:52PM +0100, Ondrej Zajicek wrote:
> On Wed, Feb 21, 2024 at 07:14:18PM +0100, Job Snijders via Bird-users wrote:
> > I'd like to be able to explicitly configure the source IP address
> > for RPKI-To-Router sessions. Predictable source addresses are useful
> > for minimizing the holes to be poked in ACLs. The below changeset
> > adds a 'source address' configuration option to RPKI protocols.
> 
> Thanks, merged:
> 
> https://gitlab.nic.cz/labs/bird/-/commit/e2728c8078161d9811d6c24a11e4c95efd1c9313
> 
> I just changed the name from 'source address' to 'local address'.

Thank you!

And kudos to the project, it was nice to observe how the pre-existing
infrastructure (like bird sockets) made this is a trivial excercise. :)

Kind regards,

Job

[patch] add 'source address' configuration option to RPKI protocols

[Job Snijders via Bird-users]

Dear BIRD team,

Greetings from Amsterdam!

I'd like to be able to explicitly configure the source IP address for
RPKI-To-Router sessions. Predictable source addresses are useful for
minimizing the holes to be poked in ACLs. The below changeset adds a
'source address' configuration option to RPKI protocols.

Kind regards,

Job

diff --git doc/bird.sgml doc/bird.sgml
index 76ca7f75..a271d47e 100644
--- doc/bird.sgml
+++ doc/bird.sgml
@@ -5700,6 +5700,7 @@ protocol rpki [name] {
 refresh [keep] num;
 retry [keep] num;
 expire [keep] num;
+source address ip;
 transport tcp;
 transport ssh {
 bird private key "/path/to/id_rsa";
@@ -5753,6 +5754,9 @@ specify both channels.
instead. This may be useful for implementing loose RPKI check for
blackholes. Default: disabled.
 
+source address 
+Define local address we should use as a source address for the RTR 
session.
+
 transport tcp Unprotected transport over TCP. It's a default
 transport. Should be used only on secure private networks.
 Default: tcp
diff --git proto/rpki/config.Y proto/rpki/config.Y
index c28cab7a..31656057 100644
--- proto/rpki/config.Y
+++ proto/rpki/config.Y
@@ -32,7 +32,7 @@ rpki_check_unused_transport(void)
 CF_DECLS
 
 CF_KEYWORDS(RPKI, REMOTE, BIRD, PRIVATE, PUBLIC, KEY, TCP, SSH, TRANSPORT, 
USER,
-   RETRY, REFRESH, EXPIRE, KEEP, IGNORE, MAX, LENGTH)
+   RETRY, REFRESH, EXPIRE, KEEP, IGNORE, MAX, LENGTH, SOURCE, ADDRESS)
 
 %type  rpki_keep_interval
 
@@ -60,6 +60,7 @@ rpki_proto_item:
  | REMOTE rpki_cache_addr
  | REMOTE rpki_cache_addr rpki_proto_item_port
  | rpki_proto_item_port
+ | SOURCE ADDRESS ipa { RPKI_CFG->local_ip = $3; }
  | TRANSPORT rpki_transport
  | REFRESH rpki_keep_interval expr {
  if (rpki_check_refresh_interval($3))
diff --git proto/rpki/rpki.h proto/rpki/rpki.h
index 8a5c38fd..e67eb0e3 100644
--- proto/rpki/rpki.h
+++ proto/rpki/rpki.h
@@ -116,6 +116,7 @@ struct rpki_proto {
 struct rpki_config {
   struct proto_config c;
   const char *hostname;/* Full domain name or 
stringified IP address of cache server */
+  ip_addr local_ip;/* Source address to use */
   ip_addr ip;  /* IP address of cache server or 
IPA_NONE */
   u16 port;/* Port number of cache server */
   struct rpki_tr_config tr_config; /* Specific transport configuration 
structure */
diff --git proto/rpki/transport.c proto/rpki/transport.c
index 81bd6dd8..26571977 100644
--- proto/rpki/transport.c
+++ proto/rpki/transport.c
@@ -82,6 +82,7 @@ rpki_tr_open(struct rpki_tr_sock *tr)
   sk->daddr = cf->ip;
   sk->dport = cf->port;
   sk->host = cf->hostname;
+  sk->saddr = cf->local_ip;
   sk->rbsize = RPKI_RX_BUFFER_SIZE;
   sk->tbsize = RPKI_TX_BUFFER_SIZE;
   sk->tos = IP_PREC_INTERNET_CONTROL;

[patch] SendHoldTimer BGP Error code

[Job Snijders via Bird-users]

Dear all,

IANA registered an "Early Allocation" BGP Error code for
draft-ietf-idr-bgp-sendholdtimer, see
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-3

The below changeset aligns bird with IANA's Border Gateway Protocol
(BGP) Parameters registry.

Kind regards,

Job

diff --git proto/bgp/bgp.c proto/bgp/bgp.c
index e97b45e6..bd6e90d6 100644
--- proto/bgp/bgp.c
+++ proto/bgp/bgp.c
@@ -1059,12 +1059,13 @@ bgp_send_hold_timeout(timer *t)
   struct bgp_conn *conn = t->data;
   struct bgp_proto *p = conn->bgp;
 
+  DBG("BGP: Send hold timeout\n");
+
   if (conn->state == BS_CLOSE)
 return;
 
-  /* Error codes not yet assigned by IANA */
-  uint code = 4;
-  uint subcode = 1;
+  uint code = 8;
+  uint subcode = 0;
 
   /* Like bgp_error() but without NOTIFICATION */
   bgp_log_error(p, BE_BGP_TX, "Error", code, subcode, NULL, 0);
diff --git proto/bgp/packets.c proto/bgp/packets.c
index 18a226fb..8320991a 100644
--- proto/bgp/packets.c
+++ proto/bgp/packets.c
@@ -3275,7 +3275,6 @@ static struct {
   { 3, 10, "Invalid network field" },
   { 3, 11, "Malformed AS_PATH" },
   { 4, 0, "Hold timer expired" },
-  { 4, 1, "Send hold timer expired" }, /* Provisional 
[draft-ietf-idr-bgp-sendholdtimer] */
   { 5, 0, "Finite state machine error" }, /* Subcodes are according to 
[RFC6608] */
   { 5, 1, "Unexpected message in OpenSent state" },
   { 5, 2, "Unexpected message in OpenConfirm state" },
@@ -3290,7 +3289,8 @@ static struct {
   { 6, 7, "Connection collision resolution" },
   { 6, 8, "Out of Resources" },
   { 7, 0, "Invalid ROUTE-REFRESH message" }, /* [RFC7313] */
-  { 7, 1, "Invalid ROUTE-REFRESH message length" } /* [RFC7313] */
+  { 7, 1, "Invalid ROUTE-REFRESH message length" }, /* [RFC7313] */
+  { 8, 0, "Send hold timer expired" } /* [draft-ietf-idr-bgp-sendholdtimer] */
 };
 
 /**

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:55:14AM +0100, Erin Shepherd wrote:
> Spitballing slightly here, but could you avoid this problem by adding
> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
> 
> Obviously the disadvantage here is that if your IRR RTR server goes
> down you're basically unfiltered, but it at least avoids the
> availability problem

That's an interesting approach, thanks for sharing this.

Kind regards,

Job

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:41:25AM +0100, Job Snijders wrote:
> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> > a quick stab at generating the slurm file:
> 
> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
> regular JSON input formatted in this style has:
> https://console.rpki-client.org/rpki.json - which might help with
> aggregation.

Err... scratch that, SLURM does have a field for that, but it's called
"maxPrefixLength". Anyway, using the 'normal' JSON format as input for
the IRR RTR server should make for a more concise smaller JSON file
compared to using SLURM prefixAssertions, but both could be used.

Kind regards,

Job

Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Job Snijders via Bird-users]

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job

Re: Expiration for ROA tables until when the VRP is valid?

[Job Snijders via Bird-users]

On Tue, Mar 07, 2023 at 01:00:40PM +0100, Job Snijders wrote:
> On Tue, Mar 07, 2023 at 12:52:16PM +0100, Ondrej Zajicek wrote:
> > If i understand it correctly, it is relevant just for static ROA
> > records?
> 
> Correct
> 
> > I assume these expiration records are based on wall-clock time instead
> > of relative time?
> 
> Correct, wall-clock time expressed as number of seconds that have
> elapsed since 00:00:00 UTC on 1 January 1970 (Unix time).
> 
> > It is a question whether we should handle expiration of such static routes
> > properly / dynamically, or just a one-time check during reconfiguration.
> > That would be order of magnitude simpler, but it is also a thing that
> > could be done by a trivial script preprocessing the included config file
> > with static ROA records.
> 
> For what its worth: OpenBGPD and StayRTR handle it 'dynamically', but
> not in absolute real time: both implementations walk a table every few
> (~3) minutes to check for newly expired entries.

To follow up with a mock configuration example, please see below.

The %lld after keyword 'expires' is calculated by OpenBSD's rpki-client
by walking the chain of authorities and keeping tabs on the 'soonest'
expiration moment. In other words, the 'expires' value is the moment a
RTR server would send an IPv4/IPv6 Prefix RTR PDU with the 'withdraw'
flag set.

(rpki-client supports generating static ROA configurations in BIRD's
format, if BIRD supports 'expires' I'll update rpki-client/output-bird.c) 

For a constantly up-to-date set of data, please download
https://console.rpki-client.org/vrps.json (as often as you want), and
transform it into BIRD's configuration format. The 'expires' key in the
JSON objects is what one would use to instruct the BGP daemon or RTR
server when to expire.

I am happy to help with this project.

Kind regards,

Job



roa4 table ROAS4;
roa6 table ROAS6;

protocol static {
  roa4 { table ROAS4; };
  route 1.0.0.0/24 max 24 as 13335 expires 1678717104; # Mon Mar 13 14:18:24 
UTC 2023
  route 1.0.4.0/24 max 24 as 38803 expires 1678751858; # Mon Mar 13 23:57:38 
UTC 2023
  route 1.7.142.0/24 max 24 as 132215 expires 1678789300; # Tue Mar 14 10:21:40 
UTC 2023
  # ...
  # left the thousands of other static entries out for brevity
}

protocol static {
  roa6 { table ROAS6; };
  route 2001:200::/32 max 32 as 2500 expires 1678724530;
  route 2001:200:136::/48 max 48 as 9367 expires 1678724530;
  route 2001:200:1ba::/48 max 48 as 24047 expires 1678724530;
  # ...
  # left the thousands of other static entries out for brevity
}

Re: Expiration for ROA tables until when the VRP is valid?

[Job Snijders via Bird-users]

On Tue, Mar 07, 2023 at 12:52:16PM +0100, Ondrej Zajicek wrote:
> If i understand it correctly, it is relevant just for static ROA
> records?

Correct

> I assume these expiration records are based on wall-clock time instead
> of relative time?

Correct, wall-clock time expressed as number of seconds that have
elapsed since 00:00:00 UTC on 1 January 1970 (Unix time).

> It is a question whether we should handle expiration of such static routes
> properly / dynamically, or just a one-time check during reconfiguration.
> That would be order of magnitude simpler, but it is also a thing that
> could be done by a trivial script preprocessing the included config file
> with static ROA records.

For what its worth: OpenBGPD and StayRTR handle it 'dynamically', but
not in absolute real time: both implementations walk a table every few
(~3) minutes to check for newly expired entries.

Kind regards,

Job

Re: Expiration for ROA tables until when the VRP is valid?

[Job Snijders via Bird-users]

On Tue, Mar 07, 2023 at 01:01:36AM +0100, Robert Scheck wrote:
> On Sun, 19 Sep 2021, Robert Scheck wrote:
> > rpki-client recently implemented the "expires" instruction for roa-sets
> > that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have
> > something similar...any chance for it? From my understanding this only
> > applies to included ROA files with VRP, not to RTR.
> > 
> > [1] https://man.openbsd.org/bgpd.conf#roa-set
> > [2] 
> > https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd72dbab99a5a71cee5707dc2
> 
> Please let me kindly repeat my initial question from about 1.5 years ago:
> Is there any chance for getting this feature into BIRD, too? Job provided
> some more details and insights as part of the original thread:
> 
>  - https://bird.network.cz/pipermail/bird-users/2021-September/015725.html
>  - https://bird.network.cz/pipermail/bird-users/2021-September/015726.html

Related, RPKI-To-Router implementation StayRTR recently received support
for honoring configured expiration timers for individual RPKI VRPs. [1]
When the expiration moment (noted as a unix timestamp) of a given RPKI
ROA/VRP has arrived, the StayRTR daemon will emit RTR Withdraws towards its
clients for that ROA/VRP.

Indeed, OpenBGPD (when loading VRPs from on-disk configuration) also
supports similar functionality, which has proven to make various
deployment scenarios less prone to faults in configuration pipelines.

I'd love it if BIRD also allows operators to specify the expiration
moment of a given ROA/VRP in the on-disk configuration through a
keyword + timestamp.

Kind regards,

Job

[1]: 
https://github.com/bgp/stayrtr/commit/13659dd27e1b792dd2a7b9f439ef0a4159d862d9

Re: [patch] Add contextual out-of-bound checks in RTR Prefix PDU handler

[Job Snijders]

Ping :-)

On Fri, 17 Sep 2021 at 21:34, Job Snijders  wrote:

> Hi,
>
> I've aligned the text that is locally logged with the encapsulated error
> message sent to the broken RPKI cache. Also fixed a compiler warning
> that snuck into my previous patch: now passing the correct pointer
> (hton_pdu) to rpki_send_error_pdu().
>
> Kind regards,
>
> Job
>
> diff --git proto/rpki/packets.c proto/rpki/packets.c
> index dd11f997..7a1eeb0f 100644
> --- proto/rpki/packets.c
> +++ proto/rpki/packets.c
> @@ -737,6 +737,30 @@ rpki_handle_prefix_pdu(struct rpki_cache *cache,
> const struct pdu_header *pdu)
>net_addr_union addr = {};
>rpki_prefix_pdu_2_net_addr(pdu, );
>
> +  if (type == IPV4_PREFIX) {
> +if (addr.roa4.max_pxlen < addr.roa4.pxlen
> +|| addr.roa4.max_pxlen > IP4_MAX_PREFIX_LENGTH
> +|| addr.roa4.pxlen > IP4_MAX_PREFIX_LENGTH) {
> +  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache
> server: invalid pxlen or max_pxlen");
> +  byte tmp[pdu->len];
> +  const struct pdu_header *hton_pdu =
> rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
> +  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, hton_pdu,
> "Corrupted PDU: invalid pxlen or max_pxlen");
> +  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
> +  return RPKI_ERROR;
> +}
> +  } else {
> +if (addr.roa6.max_pxlen < addr.roa6.pxlen
> +|| addr.roa6.max_pxlen > IP6_MAX_PREFIX_LENGTH
> +|| addr.roa6.pxlen > IP6_MAX_PREFIX_LENGTH) {
> +  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache
> server: invalid pxlen or max_pxlen");
> +  byte tmp[pdu->len];
> +  const struct pdu_header *hton_pdu =
> rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
> +  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, hton_pdu,
> "Corrupted PDU: invalid pxlen or max_pxlen");
> +  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
> +  return RPKI_ERROR;
> +}
> +  }
> +
>if (cf->ignore_max_length)
>{
>  if (type == IPV4_PREFIX)
>

Re: Expiration for ROA tables until when the VRP is valid?

[Job Snijders]

On Sun, Sep 19, 2021 at 12:38:28PM +0200, Job Snijders wrote:
> The OpenBSD RPKI validator (which can generate BIRD config snippets!)
> calculates the "transitive expiration moment". This is the 'nearest'
> moment a given ROA no longer should be considered when validating BGP
> routes. Every RPKI CA periodically refreshes/resigns data related to
> their ROAs, so every time the validation process runs, it'll output
> updated expiration moments: under normal circumstances ROAs don't drop
> out of the rotation because of expiration.

To better illustrate the feature request, I'm now generating a new BIRD2
config snippet once an hour at this URL:

http://kiera.meerval.net/bird.roa.conf.txt

I've modified this rpki-client's instance to also emit the expires %lld.
Each RPKI entry now contains an 'expires' timestamp as seconds since
epoch, which signifies the "do not use after" date. Nobody wants to
drink expired milk! :-)

Imagine a workflow where someone put in crontab:

wget -O /etc/bird/rpki.conf http://kiera.meerval.net/bird.roa.conf.txt
birdc configure

and in their /etc/bird/bird.conf a line like

include "rpki.conf";

Now, if the kiera.meerval.net service would disappear for one reason or
another, the BGP daemon won't receive new RPKI ROA information.

In that scenario, having BIRD check every few minutes whether any ROAs
it previously loaded by now have expired, can be very helpful!

Kind regards,

Job

Re: Expiration for ROA tables until when the VRP is valid?

[Job Snijders]

Hi all,

On Sun, Sep 19, 2021 at 01:07:36AM +0200, Robert Scheck wrote:
> rpki-client recently implemented the "expires" instruction for roa-sets
> that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have
> something similar...any chance for it? From my understanding this only
> applies to included ROA files with VRP, not to RTR.
> 
> [1] https://man.openbsd.org/bgpd.conf#roa-set
> [2] 
> https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd72dbab99a5a71cee5707dc2

For completeness sake, the compagnion changeset for OpenBGPD is at
https://github.com/openbsd/src/commit/fc51cb501dd3aa311d9b11d159f41d7b1e5cf33e

background:

One of the worst things for current BGP routing is to end up making
routing decisions based on last year's RPKI state. For the RTR protocol
Expiry timers already exist, but when using a 'staticly generated
ROA config' (for example via 'rtrsub') no equivalent exists (yet).

On the 'cryptographic side of the house' (in the RPKI validator) a
number of expiration moments exist for each and every RPKI ROA. For
example there is the ROA's own EE Certificate expiration date, the
parent CA's expiration moment, the parent CA's CRL nextUpdate, the
parent's parent's CA expiration, etc, etc.

The OpenBSD RPKI validator (which can generate BIRD config snippets!)
calculates the "transitive expiration moment". This is the 'nearest'
moment a given ROA no longer should be considered when validating BGP
routes. Every RPKI CA periodically refreshes/resigns data related to
their ROAs, so every time the validation process runs, it'll output
updated expiration moments: under normal circumstances ROAs don't drop
out of the rotation because of expiration.

I see two edge cases where it is useful for the BGP daemon itself to be
aware of the expiration moment for each ROA:

  * BGP speakers that have been powered off for some time, and have
RPKI-based configs on disk. The moment such a server powers back on,
and reads config from disk, it is helpful if it ignores all ROA
entries which had an expiry moment in the past

  * There is a pipeline issue: for one reason or another the file with
the RPKI ROAs don't get updated (for example the stackstorm
scheduler offline). In such a scenario it is better for the BGP
speaker to not use stale RPKI data for route selection.

The RPKI failure model is to 'fail open', not 'go stale'. Having a
(moving) expiration moment specified for each ROA helps honor signed
attestations about when to expire ROAs in end-to-end pipelines.

I'm available to work on this with BIRD developers: I can provide
real-world configs with accurate expiration moments, review, and test!

Kind regards,

Job

Re: [patch] Add contextual out-of-bound checks in RTR Prefix PDU handler

[Job Snijders]

Hi,

I've aligned the text that is locally logged with the encapsulated error
message sent to the broken RPKI cache. Also fixed a compiler warning
that snuck into my previous patch: now passing the correct pointer
(hton_pdu) to rpki_send_error_pdu().

Kind regards,

Job

diff --git proto/rpki/packets.c proto/rpki/packets.c
index dd11f997..7a1eeb0f 100644
--- proto/rpki/packets.c
+++ proto/rpki/packets.c
@@ -737,6 +737,30 @@ rpki_handle_prefix_pdu(struct rpki_cache *cache, const 
struct pdu_header *pdu)
   net_addr_union addr = {};
   rpki_prefix_pdu_2_net_addr(pdu, );
 
+  if (type == IPV4_PREFIX) {
+if (addr.roa4.max_pxlen < addr.roa4.pxlen
+|| addr.roa4.max_pxlen > IP4_MAX_PREFIX_LENGTH
+|| addr.roa4.pxlen > IP4_MAX_PREFIX_LENGTH) {
+  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache server: 
invalid pxlen or max_pxlen");
+  byte tmp[pdu->len];
+  const struct pdu_header *hton_pdu = 
rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, hton_pdu, "Corrupted 
PDU: invalid pxlen or max_pxlen");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  } else {
+if (addr.roa6.max_pxlen < addr.roa6.pxlen
+|| addr.roa6.max_pxlen > IP6_MAX_PREFIX_LENGTH
+|| addr.roa6.pxlen > IP6_MAX_PREFIX_LENGTH) {
+  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache server: 
invalid pxlen or max_pxlen");
+  byte tmp[pdu->len];
+  const struct pdu_header *hton_pdu = 
rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, hton_pdu, "Corrupted 
PDU: invalid pxlen or max_pxlen");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  }
+
   if (cf->ignore_max_length)
   {
 if (type == IPV4_PREFIX)

Re: [patch] Add contextual out-of-bound checks in RTR Prefix PDU handler

[Job Snijders]

Here is an updated version of the changeset.

The problematic PDU is now in the correct order echoed to the RTR Cache
server, making troubleshooting with tcpdump/wireshark more productive! :)

Kind regards,

Job

diff --git proto/rpki/packets.c proto/rpki/packets.c
index dd11f997..3d024504 100644
--- proto/rpki/packets.c
+++ proto/rpki/packets.c
@@ -737,6 +737,26 @@ rpki_handle_prefix_pdu(struct rpki_cache *cache, const 
struct pdu_header *pdu)
   net_addr_union addr = {};
   rpki_prefix_pdu_2_net_addr(pdu, );
 
+  if (type == IPV4_PREFIX) {
+if (addr.roa4.max_pxlen < addr.roa4.pxlen || addr.roa4.max_pxlen > 
IP4_MAX_PREFIX_LENGTH) {
+  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache server: 
invalid Max Length");
+  byte tmp[pdu->len];
+  const struct pdu_header *hton_pdu = 
rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, tmp, "Corrupted PDU");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  } else {
+if (addr.roa6.max_pxlen < addr.roa6.pxlen || addr.roa6.max_pxlen > 
IP6_MAX_PREFIX_LENGTH) {
+  RPKI_WARN(cache->p, "Received corrupt packet from RPKI cache server: 
invalid Max Length");
+  byte tmp[pdu->len];
+  const struct pdu_header *hton_pdu = 
rpki_pdu_back_to_network_byte_order((void *) tmp, (const void *) pdu);
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, tmp, "Corrupted PDU");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  }
+
   if (cf->ignore_max_length)
   {
 if (type == IPV4_PREFIX)
diff --git proto/rpki/rpki.c proto/rpki/rpki.c
index ab0837f3..91b69da0 100644
--- proto/rpki/rpki.c
+++ proto/rpki/rpki.c
@@ -288,9 +288,6 @@ rpki_cache_change_state(struct rpki_cache *cache, const 
enum rpki_cache_state ne
 
   case RPKI_CS_ERROR_FATAL:
 /* Fatal protocol error occurred. */
-rpki_force_restart_proto(cache->p);
-break;
-
   case RPKI_CS_ERROR_TRANSPORT:
 /* Error on the transport socket occurred. */
 rpki_close_connection(cache);

[patch] Add contextual out-of-bound checks in RTR Prefix PDU handler

[Job Snijders]

Hi,

A broken RPKI Cache could contextually underflow or overflow the Max
Length value in RTR IPv4 / IPv6 Prefix PDUs. Below is a changeset
proposal which adds specific out-of-bounds checks and schedules a
reconnect for a later moment. This aligns BIRD's behavior with other
COTS BGP implementations.

RFC 6810 and RFC 8210 specify that the "Max Length" value MUST NOT be
less than the Prefix Length element (underflow). On the other side
overflow of the Max Length element also is possible, it being an 8-bit
unsigned integer allows for values larger than 32 or 128.

When a PDU is received where the Max Length field is corrputed, the RTR
client (BIRD) should immediately terminate the session, flush all data
learned from that cache, and log an error for the operator.

If this condition is hit, it seems better to follow the same approach
as for RPKI_CS_ERROR_TRANSPORT, because rpki_force_restart_proto()
causes an "as fast as possible" reconnect loop between BIRD and the RPKI
Cache server, which increases resource consumption on both sides.

Kind regards,

Job

diff --git proto/rpki/packets.c proto/rpki/packets.c
index dd11f997..09e20f38 100644
--- proto/rpki/packets.c
+++ proto/rpki/packets.c
@@ -737,6 +737,22 @@ rpki_handle_prefix_pdu(struct rpki_cache *cache, const 
struct pdu_header *pdu)
   net_addr_union addr = {};
   rpki_prefix_pdu_2_net_addr(pdu, );
 
+  if (type == IPV4_PREFIX) {
+if (addr.roa4.max_pxlen > IP4_MAX_PREFIX_LENGTH || addr.roa4.max_pxlen < 
addr.roa4.pxlen) {
+  RPKI_WARN(cache->p, "Received a corrupted packet from cache server");
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, pdu, "Corrupted PDU");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  } else {
+if (addr.roa6.max_pxlen > IP6_MAX_PREFIX_LENGTH || addr.roa6.max_pxlen < 
addr.roa6.pxlen) {
+  RPKI_WARN(cache->p, "Received a corrupted packet from cache server");
+  rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, pdu, "Corrupted PDU");
+  rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL);
+  return RPKI_ERROR;
+}
+  }
+
   if (cf->ignore_max_length)
   {
 if (type == IPV4_PREFIX)
diff --git proto/rpki/rpki.c proto/rpki/rpki.c
index ab0837f3..91b69da0 100644
--- proto/rpki/rpki.c
+++ proto/rpki/rpki.c
@@ -288,9 +288,6 @@ rpki_cache_change_state(struct rpki_cache *cache, const 
enum rpki_cache_state ne
 
   case RPKI_CS_ERROR_FATAL:
 /* Fatal protocol error occurred. */
-rpki_force_restart_proto(cache->p);
-break;
-
   case RPKI_CS_ERROR_TRANSPORT:
 /* Error on the transport socket occurred. */
 rpki_close_connection(cache);

Re: ignore max length as an argument of roa_check

[Job Snijders]

On Wed, Mar 31, 2021 at 04:34:12AM +0200, Ondrej Zajicek wrote:
> So my point/idea is that if this case is valid, then using RPKI-style
> checking for BLACKHOLE is broken idea anyway, 

Yes, the design pattern of using ROAs for blackholing appears
problematic. Mangling ROAs and then using the resulting deteriorated
information to 'approve blackholes' appears to defeat the purpose of
RPKI ROAs. ROAs exist to help increase network reachability :)

> and perhaops we should instead focus on implementing (IMHO) proper
> checking for BLACKHOLE routes, similar to one for flowspec validation:
> 
>   BLACKHOLE route received from A is valid if i have (RPKI-valid)
>   regular route from A for network N covering the BLACKHOLE route
>   and (optionally) such route is best route for network N.

+1

The above appears a worthwhile direction, more elegant than overriding a
cryptographically signed attestation on the expected prefix length.
'ignore max length' appears to me as a dangerous button. I support
Pier's suggestion to remove this config knob because of the risk of
unintended consequences.

In the below slide deck I've outlined some suggestions to make
activation of blackhole requests dependent on 'normal routing', and in
doing so - any and all work to improve 'normal routing security' will
also improve 'blackholing routing'.

http://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijders.pdf

Kind regards,

Job

Re: [PATCH] BGP: Add support for BGP hostname capability

[Job Snijders]

Dear Vincent,

Thank you for your contribution, running code always is an excellent way
to move specifications for the purpose of interopability forward.

I'd like to comment on my favorite topic... *** DEFAULTS  :-)

On Wed Feb 3 19:19:50 CET 202, you wrote:
>
> However, maybe the capability should not be enabled by default.
>

Indeed, it should absolutely not be enabled by default. Enabling a
feature like this would violate the principle of least astonishment! :)

Other than POLA, there are few more reasons it probably shouldn't be
enabled by default: i recall the draft's supporters alleged this feature
is useful in context of 'datacenter networks' (aka, 'non-Internet'?).
This to me means that as only a small subset of users care about it, and
the onus is on them to enable it if they wish to use this feature.

The draft being in draft status, and not (yet?) been adopted by the IETF
IDR working group is another reason not to enable it by default.

Thirdly, the semantics of the mechanism are not entirely well aligned
with the mechanics of a node's hostname. A node's hostname can change
(often?) over the lifetime of the node, while signaling the hostname
through a BGP capability effectively limits hostname exchange merely to
the OPEN event, a single point in time.

Lastly, many have argued that this is what we have Reverse DNS for, and
then others argued that in ISIS the hostname also is flooded, so why not
in BGP... and so on, making it clear there is no consensus what to do
next.

I recommend adjusting the patch in such a way that the capability is
only exchanged with specific neighbors where the capability has been
explicitly enabled through neighbor/group specific configuration.

Kind regards,

Job

Re: export filter matches, but not announced

[Job Snijders]

On Thu, Jul 23, 2020 at 03:48:15PM -0400, micah anderson wrote:
> Alexander Zubkov  writes:
> > Please show the output of:
> > show route export nullroute
> 
> This produces nothing:
> 
> bird> show route export nullroute
> bird> 
> 
> > And why do you think it is not exported?
> 
> Besides the above, the 'show protocols all nullroute' doesn't show a
> number for the accepted column, and the peer itself doesn't see the
> route from me.

where is the 666 community added in your config, or the downstream
config?

Have you tried various 'show route' commands, possibly appeneded the
'filtered' keyword to inspect what is rejected where?

Kind regards,

Job

Re: BIRD unknown character using text editor

[Job Snijders]

have you tried running the file through the 'dos2unix' utility to remove 
Windows specific quirks from the file?

Kind regards,

Job

On Tue, Jun 2, 2020, at 11:55, Fabiano D'Agostino wrote:
> I am using a text editor on Windows to edit the bird.conf. When I get 
> my bird.conf in my linux machine and I try bird -p I get this error at 
> the end of the line:
> Unknown character
> 
> But everything is right.
> 
> How can I solve?
> 
> Thanks,
> 
> Fabiano

Re: Invalid ROA

[Job Snijders]

Hi,

On Sun, Apr 19, 2020, at 19:09, Fabiano D'Agostino wrote:
> how can I check which prefixes are not valid and so rejected? It seems 
> the rpki is working, but I'd like to be sure. I have this:
> if (roa_check(r4, net, bgp_path.last) = ROA_INVALID) then
> {
> print "Ignore RPKI invalid ", net, " for ASN ", bgp_path.last;
> 
> but I don't understand where the prints go.

They go to syslog.

Make sure to match in this: bgp_path.last_nonaggregated

Kind regards,

Job

Re: 2 upstreams 1 downstream BGP configuration optimization

[Job Snijders]

Hi Kevin,

Yes, this is normal. The routes are being rejected by the filter part that
prevents sending upstream routes from one upstream to another. Your bird
instance is aware of hundreds of thousands of paths to prefixes (routes),
but only 6 of them managed to pass your filter and be exported to your
upstream.

$ birdc show route export UPSTREAM1 all

The above command will show you what you announce to your upstream and all
details about each route such as the communities.

Kind regards,

Job

On Wed, Jun 5, 2019 at 16:54 Kevin B  wrote:

> Thank you Job and Toke.
>
> I have tried the approach of marking import routes as large bgp
> communities, can you please tell me whether it's normal that bird is
> still trying to export numerous routes to my upstreams?
>
> I did 'birdc restart [proto]' of both upstreams and this is what I get
> in 'rejected' columns:
>
> UPSTREAM1:
>
>Routes: 774396 imported, 6 exported, 774396 preferred
>Route change stats: received   rejected   filtered ignored
> accepted
>  Import updates: 777192  0  0 0 777192
>  Import withdraws:  253  0--- 0253
>  Export updates:23201221551565 768545 --- 12
>  Export withdraws:  259------ --- 783957
>
> UPSTREAM2:
>
>Routes: 758555 imported, 6 exported, 9573 preferred
>Route change stats: received   rejected   filtered ignored
> accepted
>  Import updates:1039201  0  0 41039197
>  Import withdraws:48501  0--- 22  48479
>  Export updates:4140531 8080643332455 --- 12
>  Export withdraws:41861------ ---1567606
>
> DOWNSTREAM1:
>
>Route change stats: received   rejected   filtered ignored
> accepted
>  Import updates: 22  0  0 1 21
>  Import withdraws:   783868  0--- 783864  4
>  Export updates:   10916109 28  0 ---   10916081
>  Export withdraws:   710987------ --- 710999
>
> On 6/4/19 3:14 PM, Job Snijders wrote:
> > Dear Kevin,
> >
> > On Tue, Jun 04, 2019 at 03:00:53PM +, Kevin B wrote:
> >> I have 2 upstream transit providers and 1 downstream customer we provide
> >> transit to - http://paste.debian.net/1086030/ (full Bird configuration
> with
> >> explanation)
> >>
> >> There is a problem: Bird is exporting all the imported prefixes from
> >> my upstreams back to them. For example 10.40.40.0/24 is being exported
> >> from us even when AS20's customer doesn't announce it, because it is
> >> announced somewhere else in the full table and we just export it back
> >> from the full view.
> >>
> >> Here is `birdc show protocols all` output -
> http://paste.debian.net/1086033/
> >>
> >> I would like to prevent exporting the full view tables imported from
> >> my upstreams back to them, can you help me to understand what is wrong
> >> with the configuration and why does it happen?
> > You'll have to mark the routes you receive on 'import', and act on those
> > markers on 'export'.
> >
> > I've spoken a bit about how to make robust routing policies, I hope this
> > is of use to you:
> >
> >
> https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4
> >
> >
> https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf
> >
> > Specifically in your example, I've added the use of BGP Large
> > Communities to help arrange what announcements go where, please compare
> > this untested example with your own deployment:
> http://paste.debian.net/1086041/
> >
> > Kind regards,
> >
> > Job
>

Re: 2 upstreams 1 downstream BGP configuration optimization

[Job Snijders]

Dear Kevin,

On Tue, Jun 04, 2019 at 03:00:53PM +, Kevin B wrote:
> I have 2 upstream transit providers and 1 downstream customer we provide
> transit to - http://paste.debian.net/1086030/ (full Bird configuration with
> explanation)
> 
> There is a problem: Bird is exporting all the imported prefixes from
> my upstreams back to them. For example 10.40.40.0/24 is being exported
> from us even when AS20's customer doesn't announce it, because it is
> announced somewhere else in the full table and we just export it back
> from the full view.
> 
> Here is `birdc show protocols all` output - http://paste.debian.net/1086033/
> 
> I would like to prevent exporting the full view tables imported from
> my upstreams back to them, can you help me to understand what is wrong
> with the configuration and why does it happen?

You'll have to mark the routes you receive on 'import', and act on those
markers on 'export'.

I've spoken a bit about how to make robust routing policies, I hope this
is of use to you:


https://ripe77.ripe.net/archive/video/Job_Snijders-B._BGP_Policy_Update-20181017-140440.mp4


https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf

Specifically in your example, I've added the use of BGP Large
Communities to help arrange what announcements go where, please compare
this untested example with your own deployment: http://paste.debian.net/1086041/

Kind regards,

Job

Re: Help with AS-Path manipulation

[Job Snijders]

Dear Marcio,

What is your use case for extensive manipulation of the AS_PATH?

Kind regards,

Job

On Fri, 14 Sep 2018 at 16:02, Marcio 
wrote:

> Dear,
>
> Could you help me with an information? Is there a way to generate an
> announce modifying the AS Path field using BIRD? For example, i´d like to
> announce a prefix with a false AS Path field where i could change it,
> inserting or removing an AS.
>

Re: BIRD not redistributing iBGP routes

[Job Snijders]

On Tue, Jul 31, 2018 at 01:57:53PM +0200, Matthias Merkel wrote:
> I have three BIRD routers:
> A uses iBGP only
> B also only uses iBGP
> C uses eBGP and iBGP
> 
> They are connected as follows:
> A<->B<->C (all via iBGP)
> 
> The goal is to allow A to announce routes to B, have B redistribute
> the route to C and have C announce it to the peers.
> 
> The issue is that B receives the route (and adds it to the kernel)
> however it does not send it to C.
> 
> Any ideas how to fix this?

You can perhaps configure on router B, on the sessions towards A and C
that they are route reflection clients. The relevant configuration
keyword is "rr client", see
http://bird.network.cz/?get_doc=16=bird-6.html#ss6.3

Kind regards,

Job

Re: BIRD version route server example

[Job Snijders]

instead of looking at the arouteserver examples, I strongly recommend to
just use arouteserver to generate the BIRD configurations.

IXP route servers need to do prefix filtering to ensure the safety for
all participants, and the arouteserver software can help you do this.

Kind regards,

Job

On Thu, Jul 12, 2018 at 08:42:00AM -0300, heisenbug at xpto wrote:
> arouteserver github have some good examples too:
> 
> https://github.com/pierky/arouteserver/tree/master/examples/rich
> 
> 
> []s
> 
> On 12/07/2018 05:18, Alarig Le Lay wrote:
> > Hi,
> > 
> > On jeu. 12 juil. 10:08:33 2018, Isaac HO wrote:
> >> Dear All,
> >> My BIRD version is 1.6.4. and Would like use BIRD to set up a route server.
> >>
> >> Seems there many version of BIRD..May I know the follow example config is
> >> it suitable for ersion is 1.6.4. to build up the route server.
> >>
> >>
> >> https://github.com/pierky/arouteserver/blob/master/examples/bird_hooks/bird4.conf
> > 
> > I set up a routes server some times ago, my configuration is explained
> > here:
> > https://www.swordarmor.fr/comment-monter-un-point-dechange-partie-technique-un-serveur-de-routes-avec-bird.html
> > 

Re: How to show community value

[Job Snijders]

Try adding quotes, like so:

$ birdc ‘show route where net ~ x.x.x.0/24 all‘

On Thu, 12 Jul 2018 at 11:35, Isaac HO  wrote:

> sh ip bgp x.x.x.0/24 <-- Cisco
>
> birdc show route where net ~ x.x.x.0/24 all
> BIRD 1.6.4 ready.
> root: variable expected. <-- Can't see any information.
>
> May I know have any other command?
>
> Thanks,
>

Re: bgp_next_hop check?

[Job Snijders]

On Tue, May 29, 2018 at 7:56 PM, Maria Jan Matějka  wrote:
> On May 29, 2018 8:42:22 PM GMT+02:00, Job Snijders  wrote:
>>On https://gitlab.labs.nic.cz/labs/bird/wikis/BGP_filtering I see the
>>following curious snippet:
>>
>>function xx()
>>{
>>...
>>if bgp_next_hop != from then return false;
>>...
>>}
>>
>>What in the above example does "from" mean? Is "from" some kind of
>>magic
>>keyword that expands into something?
>
> Yes. It expands to the author of the route (IP of its sender). Therefore this 
> check is to filter out routes with other next hop than the sender herself as 
> this is probably some scam or misconfiguration.

Thank you for the quick answer! Very useful

Kind regards,

Job

bgp_next_hop check?

[Job Snijders]

Dear BIRD devs,

On https://gitlab.labs.nic.cz/labs/bird/wikis/BGP_filtering I see the
following curious snippet:

function xx()
{
...
if bgp_next_hop != from then return false;
...
}

What in the above example does "from" mean? Is "from" some kind of magic
keyword that expands into something?

Kind regards,

Job

Re: BGP manage advertisement

[Job Snijders]

On Wed, May 09, 2018 at 04:35:11PM +0200, Mattia Milani wrote:
> > No. Perhaps sometimes in the future, but no definite plan.
> 
> yeah but on your site, 
> http://bird.network.cz/?get_doc=20=bird-6.html#ss6.3
> that is the user's guide 2.0, there is this written:
> 
> Supported standards
> 
>- RFC 4271 - Border Gateway Protocol 4 (BGP)
> 
> In the RFC 4271 is mentioned several times the MRAI or
> MinRouteAdvertisementIntervalTimer if you prefer, so why it isn't
> implemented?

Actually in the IETF there has been an effort to deprecate MRAI, you can
review this Internet-Draft https://tools.ietf.org/html/draft-ietf-idr-mrai-dep

This follow-up discussion may interest you as well:
https://mailarchive.ietf.org/arch/msg/idr/uNhHCoxLWLSiKH69LT4xEr6G2Jg

This is an open source project, it depends on the efforts and
contributions the BIRD community.

Kind regards,

Job

Re: BGP manage advertisement

[Job Snijders]

On Wed, May 09, 2018 at 04:12:12PM +0200, Mattia Milani wrote:
> > Why do you need (configurable) MRAI timers?
> 
> Because i'm studing a way to programmaticaly decide the MRAI timer in way
> to reduce the convergence of BGP after a node fail, so i need a MRAI
> configurable or at least implemented in the code to modify it like I think
> Maybe  thees could help you :
> https://www.noction.com/blog/bgp-path-hunting

Or perhaps not wait for MRAI timers to collapse, and just immediately
process & propagate any changes as they come in? If you want to reduce
convergence timing, is it helpful to hold back communicating state
changes to your neighbors?

If you think some form of MRAI timing is useful you can of course
attempt to implement this yourself and submit a patch.

> Look for the word "MRAI" in these RIPE Routing-WG minutes
> > https://www.ripe.net/participate/ripe/wg/routing/minutes/routing-working-group-minutes-ripe-75
>
> i didn't catch why you linked me that, i read where appear the word
> "MRAI", could you please explain what do you want to notice me?

My point is that there is contention around the topic of MRAI and there
are widely deployed 'misimplementations'. Geoff Huston's comments on
this topic are quite insightful.

Kind regards,

Job

Re: BGP.as_path parameter with '{' or '}'

[Job Snijders]

Dear all,

On Mon, Mar 19, 2018 at 12:46 PM, Mattia Milani
 wrote:
> But Alexander route aggregation is marked like "future work" on the guide
> for version 1.6.3 and version 2.0, so how it's possible to have aggregation?

This is other people doing route aggregation.
http://packetlife.net/blog/2008/sep/19/bgp-route-aggregation-part-1/

Kind regards,

Job

Re: Authentication in OSPFv3

[Job Snijders]

On Thu, Mar 15, 2018 at 10:45:09AM +, Stuart Henderson wrote:
> On 2018/03/15 08:45, Derek Pan wrote:
> > when I create a ospfv3 instance with authentication info, and I get
> > the output: “Authentication not supported in OSPFv3”
> > 
> > do you have a plan to support it or not ?
> 
> It's not BIRD. OSPFv3 doesn't support authentication.

Indeed, please review: 
http://packetlife.net/blog/2008/sep/3/ospfv3-authentication/

Kind regards,

Job

Re: what is this ( graceful restart on) does??

[Job Snijders]

On Wed, Feb 14, 2018 at 07:51:05PM +, ABBAS, KASHIF wrote:
> Need to understand what is the functionality of graceful restart….
> Can anybody please explain this graceful restart feature working in
> BIRD..

https://tools.ietf.org/html/rfc4724

Kind regards,

Job

Re: Community for small IX

[Job Snijders]

Dear Peter,

I strongly recommend to use a framework that generates your routeserver
configuration. By leveraging an existing framework you pull in important
features like prefix filtering and you leverage the work that others have
done before you.

I've had good success with arouteserver:
http://arouteserver.readthedocs.io/en/latest/

Kind regards,

Job

On Thu, Dec 28, 2017 at 4:41 PM, Piotr Marciniak  wrote:

> Hello,
>
> We are running a small IX for around 20 members. A few months ago we moved
> on Bird and actually I am trying to add some standard communities to
> prepend or stop annoucing own prefixes to other members but can’t find
> examples on Bird docs nor by Google. All I found looks limited only to
> adding fixed community only.
>
> I think it is standard and may both work on filters for main table or via
> pipe import/export filters. But still – I can’t discover how to get and
> process (to block export) or announce (with prepend) received community.
>
> Could you please direct me (or send) some examples how to do this?
>
> Thank you,
>
> Peter
>

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

[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

Re: Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

Hi Ondrej,

Thank you for your work on this patch. When sending in my code i
realised it was a bit rough on the edges, and secretly hoped that a more
experienced BIRD developer would take pity and polish it up.
Appreciated!

On Tue, Sep 26, 2017 at 02:22:20PM +0200, Ondrej Zajicek wrote:
> On Tue, Sep 26, 2017 at 10:14:11AM +0200, Peter Hessler wrote:
> > On 2017 Sep 19 (Tue) at 20:53:47 +0200 (+0200), Ondrej Zajicek wrote:
> > :Merged with some significant changes, with support for both RX and
> > TX of :shutdown communication:
> > :
> > :Unfortunately, that means that from Unix shell you have to do
> > double qouting:
> > :
> > :birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"'
> > :
> > 
> > Um, requiring double quoting violates POLA.  This isn't user
> > friendly at all.
> 
> Well, while i consider it cumbersome, i would argue that it is
> consistent with POLA. Anyone who take into account two premises,
> namely:
> 
> 1) BIRD always requires quotes for string constants
> 2) Quoting is removed by shell

I beg to differ... this is not what UNIX-style users expect from
programs. I'd expect:

$ sudo birdc disable bgp1 "hi, we will upgrade to bird 1.6.4"

or maybe 

$ sudo birdc disable bgp1 message "hi, we will upgrade to bird 1.6.4"

to work like that. 

Another aspect, from the

$ sudo birdc show protocols all bgp1

output it is not entirely clear whether the Message is the last message
that has been _sent_ to the EBGP neighbor, or is the last message that
has been _received_ from that neighbor. Might be good to clarify that a
bit (perhaps add RX or TX as prefix?).

> > It shouldn't be that hard to only require one set of quotes in both
> > the unix shell and the birdc shell.
> 
> We use the same lexer and parser for both CLI and arguments and quotes
> are not just for token separation (which is already done by shell for
> arguments), but are intrinsic part of string tokens to distinquish
> them from symbol tokens. Changing that would require significant
> changes to lexer with likely impact on backward compatibility.

I see, that is unfortunate.

Another challenge may be that the proposed patch doesn't offer feature
parity in terms of the bird.conf approach. I'm aware of many deployments
that never use "birdc enable|disable" from the command line, but just
"generate && rsync && birdc configure" to push out configs. This way the
running configuration and the startup configuration are always in sync,
which often is a desirable property.

Kind regards,

Job

Re: Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

bump? :-)

On Fri, Jul 28, 2017 at 12:26:59PM +0200, Job Snijders wrote:
> Spin #2
> 
> ---
>  proto/bgp/bgp.c | 12 +
>  proto/bgp/bgp.h |  2 ++
>  proto/bgp/packets.c | 73 
> ++---
>  3 files changed, 61 insertions(+), 26 deletions(-)
> 
> diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
> index f706e76..2a89c00 100644
> --- a/proto/bgp/bgp.c
> +++ b/proto/bgp/bgp.c
> @@ -1487,6 +1487,15 @@ bgp_last_errmsg(struct bgp_proto *p)
>  }
>  
>  static const char *
> +bgp_last_shutmsg(struct bgp_proto *p)
> +{
> +if (p->last_received_shutmsg)
> +  return(p->last_received_shutmsg);
> +else
> +  return(NULL);
> +}
> +
> +static const char *
>  bgp_state_dsc(struct bgp_proto *p)
>  {
>if (p->p.proto_state == PS_DOWN)
> @@ -1580,7 +1589,10 @@ bgp_show_proto_info(struct proto *P)
>  {
>const char *err1 = bgp_err_classes[p->last_error_class];
>const char *err2 = bgp_last_errmsg(p);
> +  const char *msg  = bgp_last_shutmsg(p);
>cli_msg(-1006, "Last error:   %s%s", err1, err2);
> +  if (msg)
> +cli_msg(-1006, "Message:  \"%s\"", msg);
>  }
>  }
>  
> diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h
> index e47a0eb..d958716 100644
> --- a/proto/bgp/bgp.h
> +++ b/proto/bgp/bgp.h
> @@ -157,6 +157,8 @@ struct bgp_proto {
>u8 last_error_class;   /* Error class of last error */
>u32 last_error_code;   /* Error code of last error. 
> BGP protocol errors
>  are encoded as (bgp_err_code << 16 | 
> bgp_err_subcode) */
> +  byte last_received_shutmsg[129];   /* RFC 8203 */
> +
>  #ifdef IPV6
>byte *mp_reach_start, *mp_unreach_start; /* Multiprotocol BGP attribute 
> notes */
>unsigned mp_reach_len, mp_unreach_len;
> diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c
> index ab87bdc..a44f264 100644
> --- a/proto/bgp/packets.c
> +++ b/proto/bgp/packets.c
> @@ -1460,9 +1460,9 @@ static struct {
>{ 5, 3, "Unexpected message in Established state" },
>{ 6, 0, "Cease" }, /* Subcodes are according to [RFC4486] */
>{ 6, 1, "Maximum number of prefixes reached" },
> -  { 6, 2, "Administrative shutdown" },
> +  { 6, 2, "Administrative shutdown" }, /* RFC 8203 can follow */
>{ 6, 3, "Peer de-configured" },
> -  { 6, 4, "Administrative reset" },
> +  { 6, 4, "Administrative reset" }, /* RFC 8203 can follow */
>{ 6, 5, "Connection rejected" },
>{ 6, 6, "Other configuration change" },
>{ 6, 7, "Connection collision resolution" },
> @@ -1497,35 +1497,56 @@ bgp_error_dsc(unsigned code, unsigned subcode)
>  void
>  bgp_log_error(struct bgp_proto *p, u8 class, char *msg, unsigned code, 
> unsigned subcode, byte *data, unsigned len)
>  {
> -  const byte *name;
> -  byte *t, argbuf[36];
> -  unsigned i;
> +const byte *name;
> +byte *t, argbuf[256];
> +unsigned i;
> +unsigned shutdown_comm_length;
>  
> -  /* Don't report Cease messages generated by myself */
> -  if (code == 6 && class == BE_BGP_TX)
> -return;
> +/* Don't report Cease messages generated by myself */
> +if (code == 6 && class == BE_BGP_TX)
> +return;
> +
> +name = bgp_error_dsc(code, subcode);
> +t = argbuf;
> +memset(p->last_received_shutmsg, 0, 128 + 1); // clear old RFC 8203 
> messages
>  
> -  name = bgp_error_dsc(code, subcode);
> -  t = argbuf;
> -  if (len)
> +if (len)
>  {
> -  *t++ = ':';
> -  *t++ = ' ';
> +*t++ = ':';
> +*t++ = ' ';
>  
> -  if ((code == 2) && (subcode == 2) && ((len == 2) || (len == 4)))
> - {
> -   /* Bad peer AS - we would like to print the AS */
> -   t += bsprintf(t, "%d", (len == 2) ? get_u16(data) : get_u32(data));
> -   goto done;
> - }
> -  if (len > 16)
> - len = 16;
> -  for (i=0; i<len; i++)
> - t += bsprintf(t, "%02x", data[i]);
> +if ((code == 2) && (subcode == 2) && ((len == 2) || (len == 4)))
> +{
> +/* Bad peer AS - we would like to print the AS */
> +t += bsprintf(t, "%d", (len == 2) ? get_u16(data) : 
> get_u32(data));
> +goto done;
> +}
> +/* RFC 8203 */
> +if ((code == 6) && ((subcode == 2 || subcode == 4)) && (len <= 129))
> +  

Re: bird: memory exhausted

[Job Snijders]

On Mon, Aug 07, 2017 at 03:01:49AM +0200, Ondrej Zajicek wrote:
> > > Any ideas how to increase the memory available to things on the stack?
> > 
> > Looks like you're hitting the Bison parser stack limit. The default
> > is 1, which is probably too low, looking at your sample config
> > file.
> 
> It is true that there is a stack limit, but the core problem is that
> involved grammar rules use right recursion instead of left recursion
> like most other rules. That causes excessive stack usage.
> 
> Workaround could to use global definitions instead of local variables, i.e:
> 
> define AS1 = [ 170.238.64.0/23, 152.231.29.0/24 ];
> 
> Also note that instead of sequence of ifs it is much more efficient to
> use case expression based on asn and then just net-based test inside of
> case branch:
> 
> case asn {
>   0: return net ~ AS0;
>   1: return net ~ AS1;
>   2: return net ~ AS2;
>   ...
> }

I implemented your approach, this indeed seesm to be an optimalisation.

Thank you! :)

Kind regards,

Job

bird: memory exhausted

[Job Snijders]

Dear all,

It appears I'm hitting some kind of limit in yacc stuff (on 1.6.3-1+trusty+1):

router# bird -c rpki-match-roa-ipv4.conf  -p
bird: rpki-match-roa-ipv4.conf, line 4998: memory exhausted

The error message is generated by generated code:

$ grep -r 'memory exhausted' *
Binary file bird matches
obj/conf/cf-parse.tab.c:yyoverflow (YY_("memory exhausted"),
obj/conf/cf-parse.tab.c:  yyerror (YY_("memory exhausted"));
Binary file obj/conf/all.o matches
Binary file obj/conf/cf-parse.tab.o matches

The config file can be found here: 
http://instituut.net/~job/rpki-match-roa-ipv4.conf.txt

Any ideas how to increase the memory available to things on the stack?

Kind regards,

Job

Re: show route

[Job Snijders]

On Tue, Aug 01, 2017 at 09:26:29AM +0200, Luk wrote:
> What is proper syntax for this kind of show route:
> 
> bird> show route protocol ECO where  net ~ 2.2.2.250/31 all
> 2.2.2.250/31 via 1.1.1.66 on eth0.930 [ECO 08:53:25] * E2 (150/200/1) 
> [1.1.1.66]
> Type: OSPF-E2 unicast univ
> OSPF.metric1: 200
> OSPF.metric2: 1
> OSPF.tag: 0x
> OSPF.router_id: 1.1.1.66
> bird> show route protocol ECO where  ospf_router_id ~ 1.1.1.66
> bird>
> 
> I expect, that second show route should show the same output as first.

Like this?

root@eunetworks-2:~# birdc show route where ospf_router_id = 
94.142.247.2 all
BIRD 1.6.3 ready.
94.142.247.2/32via 94.142.247.243 on eth8.108 [ospf1 2017-07-19 
23:09:36] * E2 (150/20/1) [94.142.247.2]
Type: OSPF-E2 unicast univ
OSPF.metric1: 20
OSPF.metric2: 1
OSPF.tag: 0x
OSPF.router_id: 94.142.247.2

Kind regards,

Job

Re: Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

Spin #2

---
 proto/bgp/bgp.c | 12 +
 proto/bgp/bgp.h |  2 ++
 proto/bgp/packets.c | 73 ++---
 3 files changed, 61 insertions(+), 26 deletions(-)

diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
index f706e76..2a89c00 100644
--- a/proto/bgp/bgp.c
+++ b/proto/bgp/bgp.c
@@ -1487,6 +1487,15 @@ bgp_last_errmsg(struct bgp_proto *p)
 }
 
 static const char *
+bgp_last_shutmsg(struct bgp_proto *p)
+{
+if (p->last_received_shutmsg)
+  return(p->last_received_shutmsg);
+else
+  return(NULL);
+}
+
+static const char *
 bgp_state_dsc(struct bgp_proto *p)
 {
   if (p->p.proto_state == PS_DOWN)
@@ -1580,7 +1589,10 @@ bgp_show_proto_info(struct proto *P)
 {
   const char *err1 = bgp_err_classes[p->last_error_class];
   const char *err2 = bgp_last_errmsg(p);
+  const char *msg  = bgp_last_shutmsg(p);
   cli_msg(-1006, "Last error:   %s%s", err1, err2);
+  if (msg)
+cli_msg(-1006, "Message:  \"%s\"", msg);
 }
 }
 
diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h
index e47a0eb..d958716 100644
--- a/proto/bgp/bgp.h
+++ b/proto/bgp/bgp.h
@@ -157,6 +157,8 @@ struct bgp_proto {
   u8 last_error_class; /* Error class of last error */
   u32 last_error_code; /* Error code of last error. BGP 
protocol errors
   are encoded as (bgp_err_code << 16 | 
bgp_err_subcode) */
+  byte last_received_shutmsg[129]; /* RFC 8203 */
+
 #ifdef IPV6
   byte *mp_reach_start, *mp_unreach_start; /* Multiprotocol BGP attribute 
notes */
   unsigned mp_reach_len, mp_unreach_len;
diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c
index ab87bdc..a44f264 100644
--- a/proto/bgp/packets.c
+++ b/proto/bgp/packets.c
@@ -1460,9 +1460,9 @@ static struct {
   { 5, 3, "Unexpected message in Established state" },
   { 6, 0, "Cease" }, /* Subcodes are according to [RFC4486] */
   { 6, 1, "Maximum number of prefixes reached" },
-  { 6, 2, "Administrative shutdown" },
+  { 6, 2, "Administrative shutdown" }, /* RFC 8203 can follow */
   { 6, 3, "Peer de-configured" },
-  { 6, 4, "Administrative reset" },
+  { 6, 4, "Administrative reset" }, /* RFC 8203 can follow */
   { 6, 5, "Connection rejected" },
   { 6, 6, "Other configuration change" },
   { 6, 7, "Connection collision resolution" },
@@ -1497,35 +1497,56 @@ bgp_error_dsc(unsigned code, unsigned subcode)
 void
 bgp_log_error(struct bgp_proto *p, u8 class, char *msg, unsigned code, 
unsigned subcode, byte *data, unsigned len)
 {
-  const byte *name;
-  byte *t, argbuf[36];
-  unsigned i;
+const byte *name;
+byte *t, argbuf[256];
+unsigned i;
+unsigned shutdown_comm_length;
 
-  /* Don't report Cease messages generated by myself */
-  if (code == 6 && class == BE_BGP_TX)
-return;
+/* Don't report Cease messages generated by myself */
+if (code == 6 && class == BE_BGP_TX)
+return;
+
+name = bgp_error_dsc(code, subcode);
+t = argbuf;
+memset(p->last_received_shutmsg, 0, 128 + 1); // clear old RFC 8203 
messages
 
-  name = bgp_error_dsc(code, subcode);
-  t = argbuf;
-  if (len)
+if (len)
 {
-  *t++ = ':';
-  *t++ = ' ';
+*t++ = ':';
+*t++ = ' ';
 
-  if ((code == 2) && (subcode == 2) && ((len == 2) || (len == 4)))
-   {
- /* Bad peer AS - we would like to print the AS */
- t += bsprintf(t, "%d", (len == 2) ? get_u16(data) : get_u32(data));
- goto done;
-   }
-  if (len > 16)
-   len = 16;
-  for (i=0; ilast_received_shutmsg, data + 1, 
shutdown_comm_length);
+goto done;
+}
+}
+else
+{
+if (len > 16)
+len = 16;
+for (i=0; ip.name, msg, name, argbuf);
+
+  done:
+*t = 0;
+log(L_REMOTE "%s: %s: %s%s", p->p.name, msg, name, argbuf);
 }
 
 static void

Re: Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

Hi,

Peter van Dijk pointed me at valgrind. It appears I can improve this
patch a bit more, stay tuned.

Kind regards,

Job

On Thu, Jul 27, 2017 at 05:55:40PM +0200, Job Snijders wrote:
> Hi all,
> 
> Here is a patch to decode received BGP shutdown communication messages
> as specified in RFC 8203. In the following example scenario I'm sending
> a shutdown communication with openbgpd:
> 
>   $ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, 
> back in 30 min"
>   request processed
> 
> And can subsequently observe the message via logging and via 'show protocols 
> all':
> 
>   job@irime:~/source/bird$ sudo ./bird -s test.sock -d -c bird2.conf
>   bird: Started
>   bird: bgp1: Received: Administrative shutdown: "TICKET-2331 we are 
> upgrading, back in 30 min"
> 
>   job@irime:~/source/bird$ sudo ./birdc -s test.sock show protocols all
> 
> BGP state:  Active
>   Neighbor address: 165.254.255.26
>   Neighbor AS:  15562
>   Connect delay:3/5
>   Last error:   Received: Administrative shutdown
>   Message:  "TICKET-2331 we are upgrading, back in 30 min"
> 
> As for the remaining RFC 8203 work:
> 
> I could use some help with _sending_ bgp shutdown communication
> messages. It is not clear to me where I should hook the message into
> the config/cli infrastructure. Ideally you can do things like:
> 
> $ birdc disable bgp1 "hi, we will upgrade to bird 1.6.4"
> 
> or via the configuration (also during reconfigure):
> 
>   protocol bgp {
>   disabled "shutdown due to maintenance ticket 2424";
>   description "My BGP uplink";
>   local 94.142.241.204 as 65000;
>   neighbor 165.254.255.26 as 15562;
>   }
> 
> Thoughts?
> 
> Kind regards,
> 
> Job
> 
> ---
>  proto/bgp/bgp.c | 13 ++
>  proto/bgp/bgp.h |  2 ++
>  proto/bgp/packets.c | 73 
> ++---
>  3 files changed, 62 insertions(+), 26 deletions(-)
> 
> diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
> index f706e76..551b156 100644
> --- a/proto/bgp/bgp.c
> +++ b/proto/bgp/bgp.c
> @@ -1487,6 +1487,16 @@ bgp_last_errmsg(struct bgp_proto *p)
>  }
>  
>  static const char *
> +bgp_last_shutmsg(struct bgp_proto *p)
> +{
> +unsigned len;
> +char *buf = calloc (128, sizeof (char));
> +len = p->last_received_shutmsg[0];
> +bsnprintf(buf, len, "%s", p->last_received_shutmsg+1);
> +return(buf);
> +}
> +
> +static const char *
>  bgp_state_dsc(struct bgp_proto *p)
>  {
>if (p->p.proto_state == PS_DOWN)
> @@ -1580,7 +1590,10 @@ bgp_show_proto_info(struct proto *P)
>  {
>const char *err1 = bgp_err_classes[p->last_error_class];
>const char *err2 = bgp_last_errmsg(p);
> +  const char *msg  = bgp_last_shutmsg(p);
>cli_msg(-1006, "Last error:   %s%s", err1, err2);
> +  if (p->last_received_shutmsg[0] > 0)
> +cli_msg(-1006, "Message:  \"%s\"", msg);
>  }
>  }
>  
> diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h
> index e47a0eb..d958716 100644
> --- a/proto/bgp/bgp.h
> +++ b/proto/bgp/bgp.h
> @@ -157,6 +157,8 @@ struct bgp_proto {
>u8 last_error_class;   /* Error class of last error */
>u32 last_error_code;   /* Error code of last error. 
> BGP protocol errors
>  are encoded as (bgp_err_code << 16 | 
> bgp_err_subcode) */
> +  byte last_received_shutmsg[129];   /* RFC 8203 */
> +
>  #ifdef IPV6
>byte *mp_reach_start, *mp_unreach_start; /* Multiprotocol BGP attribute 
> notes */
>unsigned mp_reach_len, mp_unreach_len;
> diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c
> index ab87bdc..1a021dd 100644
> --- a/proto/bgp/packets.c
> +++ b/proto/bgp/packets.c
> @@ -1460,9 +1460,9 @@ static struct {
>{ 5, 3, "Unexpected message in Established state" },
>{ 6, 0, "Cease" }, /* Subcodes are according to [RFC4486] */
>{ 6, 1, "Maximum number of prefixes reached" },
> -  { 6, 2, "Administrative shutdown" },
> +  { 6, 2, "Administrative shutdown" }, /* RFC 8203 can follow */
>{ 6, 3, "Peer de-configured" },
> -  { 6, 4, "Administrative reset" },
> +  { 6, 4, "Administrative reset" }, /* RFC 8203 can follow */
>{ 6, 5, "Connection rejected" }

Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

Hi all,

Here is a patch to decode received BGP shutdown communication messages
as specified in RFC 8203. In the following example scenario I'm sending
a shutdown communication with openbgpd:

$ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, 
back in 30 min"
request processed

And can subsequently observe the message via logging and via 'show protocols 
all':

job@irime:~/source/bird$ sudo ./bird -s test.sock -d -c bird2.conf
bird: Started
bird: bgp1: Received: Administrative shutdown: "TICKET-2331 we are 
upgrading, back in 30 min"

job@irime:~/source/bird$ sudo ./birdc -s test.sock show protocols all
  
  BGP state:  Active
Neighbor address: 165.254.255.26
Neighbor AS:  15562
Connect delay:3/5
Last error:   Received: Administrative shutdown
Message:  "TICKET-2331 we are upgrading, back in 30 min"

As for the remaining RFC 8203 work:

I could use some help with _sending_ bgp shutdown communication
messages. It is not clear to me where I should hook the message into
the config/cli infrastructure. Ideally you can do things like:

$ birdc disable bgp1 "hi, we will upgrade to bird 1.6.4"

or via the configuration (also during reconfigure):

protocol bgp {
disabled "shutdown due to maintenance ticket 2424";
description "My BGP uplink";
local 94.142.241.204 as 65000;
neighbor 165.254.255.26 as 15562;
}

Thoughts?

Kind regards,

Job

---
 proto/bgp/bgp.c | 13 ++
 proto/bgp/bgp.h |  2 ++
 proto/bgp/packets.c | 73 ++---
 3 files changed, 62 insertions(+), 26 deletions(-)

diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
index f706e76..551b156 100644
--- a/proto/bgp/bgp.c
+++ b/proto/bgp/bgp.c
@@ -1487,6 +1487,16 @@ bgp_last_errmsg(struct bgp_proto *p)
 }
 
 static const char *
+bgp_last_shutmsg(struct bgp_proto *p)
+{
+unsigned len;
+char *buf = calloc (128, sizeof (char));
+len = p->last_received_shutmsg[0];
+bsnprintf(buf, len, "%s", p->last_received_shutmsg+1);
+return(buf);
+}
+
+static const char *
 bgp_state_dsc(struct bgp_proto *p)
 {
   if (p->p.proto_state == PS_DOWN)
@@ -1580,7 +1590,10 @@ bgp_show_proto_info(struct proto *P)
 {
   const char *err1 = bgp_err_classes[p->last_error_class];
   const char *err2 = bgp_last_errmsg(p);
+  const char *msg  = bgp_last_shutmsg(p);
   cli_msg(-1006, "Last error:   %s%s", err1, err2);
+  if (p->last_received_shutmsg[0] > 0)
+cli_msg(-1006, "Message:  \"%s\"", msg);
 }
 }
 
diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h
index e47a0eb..d958716 100644
--- a/proto/bgp/bgp.h
+++ b/proto/bgp/bgp.h
@@ -157,6 +157,8 @@ struct bgp_proto {
   u8 last_error_class; /* Error class of last error */
   u32 last_error_code; /* Error code of last error. BGP 
protocol errors
   are encoded as (bgp_err_code << 16 | 
bgp_err_subcode) */
+  byte last_received_shutmsg[129]; /* RFC 8203 */
+
 #ifdef IPV6
   byte *mp_reach_start, *mp_unreach_start; /* Multiprotocol BGP attribute 
notes */
   unsigned mp_reach_len, mp_unreach_len;
diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c
index ab87bdc..1a021dd 100644
--- a/proto/bgp/packets.c
+++ b/proto/bgp/packets.c
@@ -1460,9 +1460,9 @@ static struct {
   { 5, 3, "Unexpected message in Established state" },
   { 6, 0, "Cease" }, /* Subcodes are according to [RFC4486] */
   { 6, 1, "Maximum number of prefixes reached" },
-  { 6, 2, "Administrative shutdown" },
+  { 6, 2, "Administrative shutdown" }, /* RFC 8203 can follow */
   { 6, 3, "Peer de-configured" },
-  { 6, 4, "Administrative reset" },
+  { 6, 4, "Administrative reset" }, /* RFC 8203 can follow */
   { 6, 5, "Connection rejected" },
   { 6, 6, "Other configuration change" },
   { 6, 7, "Connection collision resolution" },
@@ -1497,35 +1497,56 @@ bgp_error_dsc(unsigned code, unsigned subcode)
 void
 bgp_log_error(struct bgp_proto *p, u8 class, char *msg, unsigned code, 
unsigned subcode, byte *data, unsigned len)
 {
-  const byte *name;
-  byte *t, argbuf[36];
-  unsigned i;
+const byte *name;
+byte *t, argbuf[256];
+unsigned i;
+unsigned shutdown_comm_length;
 
-  /* Don't report Cease messages generated by myself */
-  if (code == 6 && class == BE_BGP_TX)
-return;
+/* Don't report Cease messages generated by myself */
+if (code == 6 && class == BE_BGP_TX)
+return;
+
+name = bgp_error_dsc(code, subcode);
+t = argbuf;
+memset(p->last_received_shutmsg, 0, 129); // clear old RFC 8203 messages
 
-  name = bgp_error_dsc(code, subcode);
-  t = argbuf;
-  if (len)
+if (len)
 {
-  *t++ = ':';
-  *t++ = ' ';
+*t++ = 

Re: FreeBSD, OSPF & bird 1.6.0

[Job Snijders]

Hi,

Sorry to say, but best practice is to upgrade to latest stable release and
test if the problem still exists.

Between 1.6.0 and 1.6.3 there have been a number of bug fixes and new cool
features. It makes little sense to debug an obsolete release :-)

Kind regards,

Job

Re: FreeBSD, OSPF & bird 1.6.0

[Job Snijders]

Hi,

Why are you using bird 1.6.0?

The recommended version is 1.6.3.

Kind regards,

Job

Re: Version 1.6.2

[Job Snijders]

Hi all,

Apologies for bumping up an old thread

On Fri, Sep 30, 2016 at 01:11:59AM +0200, Ondrej Zajicek wrote:
> On Thu, Sep 29, 2016 at 05:33:44PM +0200, Job Snijders wrote:
> > On Thu, Sep 29, 2016 at 05:16:24PM +0200, Ondrej Filip wrote:
> > > a new version of the 1.6.x branch is out:
> > > 
> > > Version 1.6.2 (2016-09-29)
> > >   o Fixes serious bug introduced in the previous version
> > > 
> > > Upgrade from 1.6.1 is highly recommended.
> 
> > Any hint on the schedule for the next release, which hopefully
> > includes MRT dump file rotation?
> 
> Hopefully beginning of 2017.

Can I maybe help testing this feature?

The use case is that I operate a large public BGP Looking Glass for the
NLNOG RING project at http://lg.ring.nlnog.net/summary/lg01/ipv4 BIRD is
used as the collector as it is quite fast and memory efficient.

What I hope to be able to do at some point is to log all BGP updates
from the peers periodically take a full dump, and store those in long
term archives. Those archives will be made available to the public for
research & operational purposes similar to route-views and RIPE RIS.

Kind regards,

Job

Re: Version 2.0.0-pre1

[Job Snijders]

On Mon, May 01, 2017 at 11:45:58AM +0200, Ondrej Zajicek wrote:
> On Sun, Apr 30, 2017 at 10:42:19AM +0200, Job Snijders wrote:
> > On Sun, Apr 30, 2017 at 12:46:04AM +0200, Ondrej Filip wrote:
> > > Let me announce a new addition to 2.0.x branch.
> > 
> > Congratulations!
> > 
> > Does this 2.0.0-pre1 version follow draft-ietf-grow-bgp-reject ? 
> 
> No, like 1.6.x, it has default policy of import all, export none.
>
> While i see that it is a good idea to have export none as default, i
> do not see much advantage to have import none as default.

I'd argue this is insecure behaviour and I'm disappointed you do not see
an advantage.

The default of "import all" fully relies on the EBGP neighbor not
announcing crap to you. Relying on others to do the right thing means
you are operating from a position of weakness rather then strength.

And while today your peering partner may announce a pristine set of
routes, tomorrow that might be different. Your EBGP peer could update
their configuration, upgrade the software, or swap out their
implementation for something with poor defaults. This can lead to
surprises (outages) to both parties if they are not incentivized to
ensure that both sides of the EBGP session make a conscience decision
what to accept and what to reject. 

You may want to align with feela@ since it appears you have different
opinions on the matter. Ondrej Filip told me that 2.0.x would be the
right place for a change like this and earlier on committed to support
this secure default behaviour.

Kind regards,

Job

filters, line 1360: ~ applied on unknown type pair

[Job Snijders]

Hi all,

I see the following pop up in the syslog, over and over again:

root@eunetworks-2:/etc/bird# tail -F /var/log/syslog | grep filters
Feb 24 19:34:32 eunetworks-2 bird: filters, line 1360: ~ applied on 
unknown type pair
Feb 24 19:34:32 eunetworks-2 bird: filters, line 1360: ~ applied on 
unknown type pair
Feb 24 19:34:32 eunetworks-2 bird: filters, line 1360: ~ applied on 
unknown type pair
Feb 24 19:34:32 eunetworks-2 bird: filters, line 1360: ~ applied on 
unknown type pair
Feb 24 19:34:32 eunetworks-2 bird: filters, line 1360: ~ applied on 
unknown type pair

However, tracing down where the error comes from is not so trivial:

root@eunetworks-2:/etc/bird# find /etc/bird -type f | xargs grep 
include  | wc -l
302
root@eunetworks-2:/etc/bird# du -sh /etc/bird
48M/etc/bird
root@eunetworks-2:/etc/bird#

I have a glorious spaghetti spread over almost 50 megabytes of config.

Anyone got any idea why I'm seeing this warning, and how I can figure
out what BIRD considers 'line 1360'?

Kind regards,

Job

Re: BLACKHOLE community RFC7999

[Job Snijders]

On Fri, Oct 21, 2016 at 10:24:25AM +, Thomas King wrote:
> Hi all,
> 
> > We could add option 'interpret blackhole' (disabled by default),
> > which could be used to enable RFC 7999 behavior.
> 
> I would prefer to have a 'interpret blackhole' switch because it makes
> it really easy to use.

how will the software know whether the bgp neighbor is authorised to
advertise and blackhole a prefix?

to me an important part of the RFC is that the operator is still
obligated to do his/her work and create filters, policy, etc.

Kind regards,

Job

Re: Version 1.6.2

[Job Snijders]

Hi Ondrej,

On Thu, Sep 29, 2016 at 05:16:24PM +0200, Ondrej Filip wrote:
> a new version of the 1.6.x branch is out:
> 
> Version 1.6.2 (2016-09-29)
>   o Fixes serious bug introduced in the previous version
> 
> Upgrade from 1.6.1 is highly recommended.

Thank you!

When will Debian packages for 1.6.2 be available at
http://bird.network.cz/?download=debian/pool/main/b/bird/ ?

Any hint on the schedule for the next release, which hopefully includes
MRT dump file rotation?

Kind regards,

Job

Re: MRTdump (Was: Re: New in BIRD)

[Job Snijders]

Hi,

Sorry for resurrecting an old thread like this, but I was wondering
whether any progress has been made for automatic MRT dump file rotation?

I believe there is a patch, and i thought it would be merged into 1.6.0
- but than little happened :(

The use case is that I have a big route collector with 41,000,000 routes
in RIB, which i'd like to dump into long term archives for research
purposes, but without file rotation that will be hard to do.

Kind regards,

Job

On Fri, May 30, 2014 at 08:57:39AM +0200, Job Snijders wrote:
> On Thu, May 29, 2014 at 11:21:01PM +0200, Ondrej Zajicek wrote:
> > On Tue, May 27, 2014 at 08:42:04PM +0900, Ilias Pallikarakis wrote:
> > > Hi,
> > > I figured out that my problem was simply not configuring BIRD for  
> > > multihop neighbour.
> > > I have, however, another question if someone would care to answer. From my
> > > search so far I came to the conclusion that in BIRD you cannot mrtdump  
> > > to more
> > > than one file (per process) and that it is still not possible to  
> > > periodically dump a
> > > table. Is that correct ?
> > 
> > That is true. MRTdump was on border of my interests but it could be
> > easily extended. What features w.r.t. MRTdump would be considered
> > useful?
> 
> Automatic file rollover would be a great feature!
> 
> Have the BIRD process periodically (say every hour) close the MRT file,
> and open a new one with a new filename which has the date in it.
> Bonuspoints for making these intervals configurable :-)
> 
> Kind regards,
> 
> Job

Re: New "channels" feature in future version of Bird?

[Job Snijders]

On Fri, Jun 17, 2016 at 01:40:45PM +0200, Jan Matejka wrote:
> If one of our crazy ideas comes true, we may add Lua as a possible
> language to write filters in (in several years' perspective) and maybe
> also deprecate the current, then-legacy filter language in far future.

YES!!! that would be awesome :)

Kind regards,

Job

Re: Version 1.6.0

[Job Snijders]

Hi Ondrej,

On Fri, Apr 29, 2016 at 06:35:33PM +0200, Ondrej Filip wrote:
> Dear Bird users,
> the long expected version is out:
> 
> Version 1.6.0 (2016-04-29)
>   o Major RIP protocol redesign
>   o New Babel routing protocol
>   o BGP multipath support
>   o KRT: Add support for plenty of kernel route metrics
>   o KRT: Allow more than 256 routing tables
>   o Static: Allow to specify attributes for static routes
>   o Static: Support for BFD controlled static routes
>   o FreeBSD: Setup password for BGP MD5 authentication
>   o IO: Remove socket number limit
>   o Plenty of bug fixes
> 
>   Upgrade notes:
> 
>   For RIP, most protocol options were moved to interface blocks.
> 
> Enjoy!

Sure thing! :)

When will Debian packages for 1.6.0 be available at
http://bird.network.cz/?download=debian/pool/main/b/bird/ ?

Any hint on the schedule for the next release, which hopefully includes
mrt dump file rotation?

Kind regards,

Job

Re: integration with Fastnetmon

[Job Snijders]

On Mon, Feb 01, 2016 at 08:48:15AM +, Neil Morris wrote:
> I have just started looking into BIRD for use with Fastnetmon for DDoS
> mitigation.  I see that ExaBGP is aready integrated with Fastnetmon,
> but was interested to hear from anyone who has used BIRD.

I've intergrated BIRD and fastnetmon in AS8283 and documented it in this
video: https://www.youtube.com/watch?v=0ahdxp_btHY

Kind regards,

Job

pattern matching for bgp communities

[Job Snijders]

Hi all,

Is there a way to do pattern matching or regex matching on the BGP
communities associated with a prefix?

The use-case I have: an eBGP peer attaches communties which inform me
both about the geographical point of origin and the type of relation my
eBGP peer has with the remote network adjacent to them. In their scheme
they treat the lower 16 bits of the BGP community as a string of sorts,
where the first digit represents continent and the second digit the type
of relation:

so "65535:12" might mean (after removnig the '65535' part, "12"
remains), the "1" signifies the continent (say europe), the "2"
signifies the relation (say 'peering').

Should I want to accept all routes where the relation is equals say "3",
I'd have to either create a list of all possible communities matching
where relation is "3", you'd end up with something like this:

function filter_rel_type()
clist l;
{
l = [(65535, 3),  (65535, 13),  (65535, 23),  (65535, 33),
(65535, 43),  (65535, 53),  (65535, 63),  (65535, 73),
(65535, 83),  (65535, 93)];
if l ~ bgp_community then return true;
return false;
}


You can imagine that with more complex informational scheme's 'clist l'
would grow to rather large proportions.

Is there a more elegant way to accomplish this style of matching?

Kind regards,

Job

Re: MRT rib dump support

[Job Snijders]

On Thu, Nov 12, 2015 at 04:55:50PM +0100, Ondrej Zajicek wrote:
> On Wed, Nov 11, 2015 at 11:46:17AM -0800, Evelio VILA wrote:
> > Hello,
> > 
> > I just came across this commit
> > 
> > https://gitlab.labs.nic.cz/labs/bird/blob/3e3e381b98fe8809b560da7cd5dc95641102f1cd/nest/mrtdump.c
> > 
> > Any ideas when is the feature planned for release :)
> 
> Hello, likely in the next release.

Will a 'rotate' function of sorts be implemented? Where you can specify
that every 3600 seconds it starts writing to the next file, with for
instance a UNIX timestamp being part of the filename?

Kind regards,

Job

Re: BFD and Juniper?

[Job Snijders]

On Sat, Aug 15, 2015 at 02:42:11PM +, Leighton, Russell wrote:
 I'm trying to get bird 1.5.0 to have BFD work with Juniper MX Routers.
 
 Sessions  get stuck in Init state with the Juniper side in Down state.
 
 Any suggestions?

On the BIRD box, set this in sysctl.conf:

net.ipv4.ip_local_port_range=49152 65535

BIRD config:

protocol bfd bfd1 {
interface ;
}

protocol bgp neighbor1 {
[ ... ]
bfd on;
}

On the Juniper side something like this:

j...@eunetworks-1.router.nl.coloclue.net show configuration protocols bgp 
group internal-ipv4 neighbor 94.142.247.237 bfd-liveness-detection
minimum-interval 10;
multiplier 5;
transmit-interval {
minimum-interval 100;
}

Kind regards,

Job