Hi All, We've been working on an extension to BIRD supporting the BGPSec protocol that is currently being discussed in the IETF SIDR Working Group. And I had some questions I wanted to ask the BIRD developers. If the user list isn't the appropriate forum, let me know and we can discuss it elsewhere or offline. We've made some initial progress, although it's not even to what I would call an Alpha stage yet. Our current plan is to have a beta/alpha working by the beginning of Summer and to continue work on it for up to a year afterwords. We would like to have the work contributed back to the BIRD project. Which brings me to the questions I had. Is the BIRD team interested in the contribution? Are we in conflict with any work you are doing to support BGPSec? (I haven't seen any mention on the user list, but I don't know if there has been any work otherwise). Assuming you are interested, besides that our code should have a compatible license, i.e. GPL, and it should try match the coding style of the files that are modified, are there any other requirements or desires that you may have regarding code enhancements and contributions to the BIRD project? Thanks, Mike -- Michael Baer baerm@tislabs.com
Hi Mike, do you also intend to implement prefix origin validation according to IETF/SIDR specs? Maybe as a side note: We implemented the RTR protocol as a lightweight and very efficient C library, which allows to exchange validated ROAs between cache and router and to perform origin validation. The implementation is under LGPL license. It is designed to be integrated into existing BGP daemons. Feel free to use it. Further details: * http://rpki.realmv6.org/ If you have further questions about the library, don't hesitate to contact me offlist. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Tue, 20 Mar 2012, Michael Baer wrote:
Hi All,
We've been working on an extension to BIRD supporting the BGPSec protocol that is currently being discussed in the IETF SIDR Working Group. And I had some questions I wanted to ask the BIRD developers. If the user list isn't the appropriate forum, let me know and we can discuss it elsewhere or offline.
We've made some initial progress, although it's not even to what I would call an Alpha stage yet. Our current plan is to have a beta/alpha working by the beginning of Summer and to continue work on it for up to a year afterwords.
We would like to have the work contributed back to the BIRD project. Which brings me to the questions I had. Is the BIRD team interested in the contribution? Are we in conflict with any work you are doing to support BGPSec? (I haven't seen any mention on the user list, but I don't know if there has been any work otherwise). Assuming you are interested, besides that our code should have a compatible license, i.e. GPL, and it should try match the coding style of the files that are modified, are there any other requirements or desires that you may have regarding code enhancements and contributions to the BIRD project?
Thanks, Mike
On Tue, Mar 20, 2012 at 07:23:19PM +0100, Matthias Waehlisch wrote:
Hi Mike,
do you also intend to implement prefix origin validation according to IETF/SIDR specs?
Maybe as a side note: We implemented the RTR protocol as a lightweight and very efficient C library, which allows to exchange validated ROAs between cache and router and to perform origin validation.
We have beta ROA checking in GIT code and will be a part of the next release, which will be in a few days. Currently, it is just a local part (ROA data structure and filters with possibility to statically configure ROAs or add/remove them dynamically using birdc), integration with RPKI / RTR exchange protocol is planned to be added later, i will probably embed or reuse your library. BTW, if i remember correctly, connection between router and RPKI cache is required to be SSH protected, how do you handle that in your library? Reuse external SSH tool, library or integrate all the cryptography? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
Hi Ondrej, On Tue, 20 Mar 2012, Ondrej Zajicek wrote:
do you also intend to implement prefix origin validation according to IETF/SIDR specs?
Maybe as a side note: We implemented the RTR protocol as a lightweight and very efficient C library, which allows to exchange validated ROAs between cache and router and to perform origin validation.
We have beta ROA checking in GIT code and will be a part of the next release, which will be in a few days. Currently, it is just a local part (ROA data structure and filters with possibility to statically configure ROAs or add/remove them dynamically using birdc), integration with RPKI / RTR exchange protocol is planned to be added later, i will probably embed or reuse your library.
great! If you need any insights into to lib or if you have suggestions for improvements, please let me know! We are defintely open for collaboration.
BTW, if i remember correctly, connection between router and RPKI cache is required to be SSH protected, how do you handle that in your library? Reuse external SSH tool, library or integrate all the cryptography?
SSH is not mandatory. We support SSH based on the libssh. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
On Tue, 20 Mar 2012 19:23:19 +0100, Matthias Waehlisch <waehlisch@ieee.org> said:
MW> Hi Mike, do you also intend to implement prefix origin MW> validation according to IETF/SIDR specs? We are planning to do prefix origin validation (it would be kind of pointless otherwise). Likely, with another tool and then RTR to a local cache. How much was going to be local and remote I'm not sure. But thanks for mentioning the RTR C Library, it may be useful for us. -Mike MW> Maybe as a side note: We implemented the RTR protocol as a MW> lightweight and very efficient C library, which allows to MW> exchange validated ROAs between cache and router and to perform MW> origin validation. The implementation is under LGPL license. It MW> is designed to be integrated into existing BGP daemons. Feel MW> free to use it. MW> Further details: MW> * http://rpki.realmv6.org/ MW> If you have further questions about the library, don't MW> hesitate to contact me offlist. MW> Cheers matthias MW> -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer MW> Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany MW> .. mailto:waehlisch@ieee.org MW> .. http://www.inf.fu-berlin.de/~waehl :. Also: MW> http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net MW> On Tue, 20 Mar 2012, Michael Baer wrote: >> >> Hi All, >> >> We've been working on an extension to BIRD supporting the BGPSec >> protocol that is currently being discussed in the IETF SIDR >> Working Group. And I had some questions I wanted to ask the BIRD >> developers. If the user list isn't the appropriate forum, let me >> know and we can discuss it elsewhere or offline. >> >> We've made some initial progress, although it's not even to what >> I would call an Alpha stage yet. Our current plan is to have a >> beta/alpha working by the beginning of Summer and to continue >> work on it for up to a year afterwords. >> >> We would like to have the work contributed back to the BIRD >> project. Which brings me to the questions I had. Is the BIRD >> team interested in the contribution? Are we in conflict with any >> work you are doing to support BGPSec? (I haven't seen any mention >> on the user list, but I don't know if there has been any work >> otherwise). Assuming you are interested, besides that our code >> should have a compatible license, i.e. GPL, and it should try >> match the coding style of the files that are modified, are there >> any other requirements or desires that you may have regarding >> code enhancements and contributions to the BIRD project? >> >> Thanks, Mike >> >> -- Michael Baer baerm@tislabs.com
On Tue, Mar 20, 2012 at 11:11:44AM -0700, Michael Baer wrote:
Hi All,
We've been working on an extension to BIRD supporting the BGPSec protocol that is currently being discussed in the IETF SIDR Working Group. And I had some questions I wanted to ask the BIRD developers. If the user list isn't the appropriate forum, let me know and we can discuss it elsewhere or offline.
I guess user list is appropriate. Personally, i do not believe in user/developer mailing list splits.
We've made some initial progress, although it's not even to what I would call an Alpha stage yet. Our current plan is to have a beta/alpha working by the beginning of Summer and to continue work on it for up to a year afterwords.
We would like to have the work contributed back to the BIRD project. Which brings me to the questions I had. Is the BIRD team interested in the contribution? Are we in conflict with any work you are doing to support BGPSec? (I haven't seen any mention on the user list, but I don't know if there has been any work otherwise). Assuming you are interested, besides that our code should have a compatible license, i.e. GPL, and it should try match the coding style of the files that are modified, are there any other requirements or desires that you may have regarding code enhancements and contributions to the BIRD project?
We are interested in contributions, although it sometimes took a while to get reviewed and merged, esp. if it is an invasive patch. We don't have any current plans on BGPSec, AFAIK. GPL; coding style similar to one used in nest, BGP or OSPF and reusing existing elements and code patterns instead of reinventing wheel is probably enough. It is a good idea to write some overview (how it will be integrated in the current code) beforehand, esp. for invasive changes to the current code or non-standard interactions with the rest of BIRD. I don't know BGPSec, bug i see some possible problems - first, BGP code (and most of BIRD route propagation), is synchronous, which is probably not well suited for cryptographic validation. Second, how cryptographic code would be connected - external tool for validation, external lib, internal lib. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On Tue, 20 Mar 2012 22:58:02 +0100, Ondrej Zajicek <santiago@crfreenet.org> said:
Ondrej> On Tue, Mar 20, 2012 at 11:11:44AM -0700, Michael Baer wrote: >> >> Hi All, >> >> We've been working on an extension to BIRD supporting the BGPSec >> protocol that is currently being discussed in the IETF SIDR >> Working Group. And I had some questions I wanted to ask the BIRD >> developers. If the user list isn't the appropriate forum, let me >> know and we can discuss it elsewhere or offline. Ondrej> I guess user list is appropriate. Personally, i do not Ondrej> believe in user/developer mailing list splits. With only one list and not a high message load, it looked to me like this would be a good forum. But I wanted to be sure and ask. >> We've made some initial progress, although it's not even to what >> I would call an Alpha stage yet. Our current plan is to have a >> beta/alpha working by the beginning of Summer and to continue >> work on it for up to a year afterwords. >> >> We would like to have the work contributed back to the BIRD >> project. Which brings me to the questions I had. Is the BIRD >> team interested in the contribution? Are we in conflict with any >> work you are doing to support BGPSec? (I haven't seen any mention >> on the user list, but I don't know if there has been any work >> otherwise). Assuming you are interested, besides that our code >> should have a compatible license, i.e. GPL, and it should try >> match the coding style of the files that are modified, are there >> any other requirements or desires that you may have regarding >> code enhancements and contributions to the BIRD project? Ondrej> We are interested in contributions, although it sometimes Ondrej> took a while to get reviewed and merged, esp. if it is an Ondrej> invasive patch. Ondrej> We don't have any current plans on BGPSec, AFAIK. Ondrej> GPL; coding style similar to one used in nest, BGP or OSPF Ondrej> and reusing existing elements and code patterns instead of Ondrej> reinventing wheel is probably enough. It is a good idea to Ondrej> write some overview (how it will be integrated in the Ondrej> current code) beforehand, esp. for invasive changes to the Ondrej> current code or non-standard interactions with the rest of Ondrej> BIRD. Ondrej> I don't know BGPSec, bug i see some possible problems - Ondrej> first, BGP code (and most of BIRD route propagation), is Ondrej> synchronous, which is probably not well suited for Ondrej> cryptographic validation. Second, how cryptographic code Ondrej> would be connected - external tool for validation, external Ondrej> lib, internal lib. Generating the local cert info was going to be asynchronous to BIRD. The validation, at least initially, will be synchronous using openssl. It may be a problem for high capacity routers. I'd guess for medium use/decent hardware or low use routers that it won't be much of an issue. But since we haven't gotten far enough along to see the cpu load during update validation, it's a pretty limited guess. -Mike -- Michael Baer baerm@tislabs.com
participants (3)
-
Matthias Waehlisch -
Michael Baer -
Ondrej Zajicek