On Fri, Apr 1, 2011 at 11:05 PM, Hannes Gredler <[email protected]> wrote: > On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote: > | Hi John, > | > | On Fri, 1 Apr 2011, John Scudder wrote: > | > | > > i propose that i rev the doc to say > | > > o the transport must provide authentication and integrity > | > > o the current ssh description is an example > | > > o other transport meeting the authentication and integrity constraints > | > > are welcome > | > > > | > > of course, this will leave open the mandatory-to-implement LCD issue. > | > > sigh. > | > > | > I think we shouldn't punt on a mandatory transport. I suggest TCP-MD5 > | > for practical reasons, including the open source support issue Chris > | > raised. > | > > | I'm confused: Do you suggest TCP-MD5 as optional or mandatory? > | > | Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by > | AO. I'm not sure how the IESG would react on this. On the other hand, if > | there are no real implementations for RFC5925 it seems useless for RTR, > | as well. Thus, I would stick to SSH (or something else that is > | well-deployed and not obsoleted). > > the practical problem i have with SSH is that it is pretty hard to > integrate into to the async/non-blocking I/O APIs that we work with typically. > openssh is select() based which does not scale terribly well if you have > e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs).
So, if the configured limit of cache's was 5 would that make your arguement change in any way? (5 as an example) > modern, scalable I/O stacks in router OSes are exclusively based on Kqueue > or Epoll. > for your reference libevent has some nice description for this: > see http://monkey.org/~provos/libevent/ > > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention that i > am no security guy ;-)), since those are the standard tools to protect message > integrity of the BGP session itself - its already onboard and does not cause > much > userspace / userspace transport weirdness since both for linux and BSD its > implemented in the kernel. > > /hannes > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
