On Mon, May 14, 2012 at 11:18 AM, [email protected] <[email protected]> wrote: > Hardware cryptoprocessors raise the issue of export licenses. They are > also expensive. There will have to be software alternatives.
the vendors who've been involved so far didn't mention export-problems, but that's a fair thing to keep in mind. The cost is also interesting, but on the other side of a 200k USD device, is the coprocessor (if needed at all, and if ONLY used for this function) a show stopper at 100 USD/item? (at 1000? what is an average cost Sriram?) > If we want widespread adoption, there must be an option to "just turn > it on" without having to shell out a load of extra money and fill a > lot of forms. sure. > Security usability means more than just a zero-marginal-cost software > implementation. It means easy setup of keys and certificates, and > probably the option of running in "advisory more" where verification > failures raise error messages but do not cause routes to fail. That I think in no case will the validation just drop a route, or the plan so far has simply been adding an ability to mark an update with some key (community, localpref, etc) and use that in determining what to do with the route. If you can match on validity state you COULD simply DROP the route, but I don't think that'll be the end state for a very, very long time. > will enable ASes to try, watch, and gain the confidence to turn it on. > > Who's looking at security usability? smb? would you like to help? :) ^^^ - probably others as well, but he's been a voice so far, as has mr turner. -chris > Ross > > > On 14/05/2012, Christopher Morrow <[email protected]> wrote: >> On Mon, May 14, 2012 at 10:27 AM, Brian Dickson >> <[email protected]> wrote: >>> We can't do the crypto without HW on some of the routers involved in >>> deployment of bgpsec. >>> >>> I've heard just about everyone say that, quite possibly including >>> yourself. >> >> I don't think I've said that recently, one of the items brought out >> during discussions of this was that often the hardware accelerators >> for this are optimised for 'use one key a lot', not for 'swap in a new >> key for every operation' (the key swap is very costly). >> >> Sriram has some numbers for different co-processors which are >> interesting, but I don't think that means we need on-board crypto >> accelerators. >> >>> One of the reasons for questioning the choice of crypto, is exploring the >>> feasibility of solutions which do not require on-router HW for doing >>> signing. >> >> sure, but you also invented a whole other (seemingly complex) system >> to keep track of data (nonces and such) across multiple >> trust/administrative domains. it seems unwieldy, to me at least. >> >> One of the larger stumbling blocks though is ram for RIB storage. (or >> that seems to be one of the larger problems to address) >> >> -chris >> >>> >>> Brian >>> >>> >>> On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow >>> <[email protected]> wrote: >>>> >>>> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson >>>> <[email protected]> wrote: >>>> > The argument that "we can't do the crypto without HW" >>>> >>>> i didn't see anyone say that though. >>> >>> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
