From e8696ac484f50de2f173968d608544f5e6c859bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kate=C5=99ina=20Kubecov=C3=A1?= Date: Wed, 26 Jun 2024 09:23:12 +0200 Subject: [PATCH] TCP-AO implementation based on RFC 5925, used Linux TCP-AO. Tested against JUNIPER. --- doc/bird.sgml | 46 ++++++++ lib/socket.h | 38 +++++++ proto/bgp/bgp.c | 235 +++++++++++++++++++++++++++++++++++++++- proto/bgp/bgp.h | 2 + proto/bgp/config.Y | 95 +++++++++++++++- proto/bgp/packets.c | 45 ++++++++ sysdep/linux/sysio.h | 247 ++++++++++++++++++++++++++++++++++++++++++ sysdep/linux/tcp-ao.h | 109 +++++++++++++++++++ sysdep/unix/io.c | 17 ++- 9 files changed, 826 insertions(+), 8 deletions(-) create mode 100644 sysdep/linux/tcp-ao.h diff --git a/doc/bird.sgml b/doc/bird.sgml index ced927d4..7519a2ed 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2912,6 +2912,38 @@ using the following configuration parameters: set manually by an external utility on NetBSD and OpenBSD. Default: enabled (ignored on non-FreeBSD). + + This authentication is similar to md5, but enables changing keys on living connection. + Key change is done via reconfiguring. + + Key configuration of one key consists of two ids - one for local and one for remote machine. + The ids may, but does not have to be the same and must be in range 0 - 255. Among keys + on one protocol the local ids must be unique and the remote ids must be unique. + + Used cryphtographic algorithm must be specified for each key. + Possible ciphers are "cmac(aes128)", "hmac(md5)" "hmac(sha1)", "hmac(sha224)", + "hmac(sha256)", "hmac(sha384)" and "hmac(sha512)". And, of course, there must + be specified a string password. + + One key must be marked as "required". This key will be send as rnext key. + If the other site knows the required key, it uses the key for next packet. + + In order to delete a currently used key (key which is required by the other site), + it is possible to mark the key as "deprecated". This key will be deleted first time + the other site requires another key. + + Deleting a currently used key in config causes restart of the protocol. + The problem of directly deleting current key is, that we could treat such deleted key as deprecated, + but only until the protocol restarts. If it restarts, key is lost. + For example, connection is established. Then one side decides to remove current key and requires a newly added key. + The other side does not know the new key yet. For now, this is not problem, they still use the old key. + But, at this moment, some unexpected error occures at the first site. + It restarts, but it does not have the old key in config. One site does not have old key, + the other new key and trying other keys than required ones is not supported. + + Editing existing keys (except of marking them "required" or "deprecated") + is not recommended and leads to restarting protocol. +