Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Hannes Gredler <[e-mail]>]

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).

  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