On Fri, Apr 01, 2011 at 11:21:03PM +0200, Christopher Morrow wrote: | 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)
no, as all my other "userspace" apps using TCP (in our case BGP, LDP, MSDP and rpki-cache) are all using Kqueue which makes it very simple to come up with an implementation which scale nicely under load; mixing select() with Kqueue in a daemon that has potentially 1000s of sessions would blow FD_SET to 16384, requires changing the main eventloop etc., all non-trivial changes. i mean why should i take a step backward to a select() based model just to get encryption which i do not need. - don't get me wrong SSH is great for a variety of purposes, but its certainly not the best toolkit to build a scalable transport between a client and a server. another alternative is to move the rpki-cache protocol into a sep. userspace daemon, then you are right, there is no need to be worried about the select()ism of the openssh lib, however then the performance for validating a BGP stream gets a hit by all the IPC overhead between the daemons. i remember from one of the early discussions with randy that he's very cautious about the validation overhead. | > 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
