On Sat, Jun 4, 2011 at 10:02 AM, Joe Touch <[email protected]> wrote: > So basically the problem is that: > > - routers don't all support IPsec for the control plane > > - servers don't yet implement AO
routers don't yet support AO either :( at least not in juniper 10.x code nor cisco 12.2(S) or 15 code... (or not that I've seen and been able to configure, though at least 1 of the 2 there say 'coming RSN!') > I repeat that there's a known solution that is already being used for BGP: > > Use AO if available > > Use MD5 in the meantime > ok, I think that's kind of where the implementors got in offline discussions. I think people (me at least) are hoping the security AD folks find this sort of wording/direction palatable though. > Yes, servers will support AO, if for no other reason than they support BGP > and MD5 now. agreed, some heat is required to make this happen (heat == 'gosh I'd love my Oracle/fbsd/linux server(s) to be able to run quagga to my new and old IOS boxes...') -chris > Joe > > On Jun 3, 2011, at 7:26 PM, Christopher Morrow <[email protected]> > wrote: > >> On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri <[email protected]> >> wrote: >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Christopher Morrow >>> Sent: Friday, June 03, 2011 6:11 PM >>> To: Uma Chunduri >>> Cc: Sandra Murphy; [email protected]; [email protected] >>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>> >>> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <[email protected]> >>> wrote: >>>> >>>> >>>> -----Original Message----- >>>> From: Sandra Murphy [mailto:[email protected]] >>>> Sent: Friday, June 03, 2011 1:43 PM >>>> To: Uma Chunduri >>>> Cc: [email protected]; Sean Turner; [email protected] >>>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? >>>> >>>> >>>> On Fri, 3 Jun 2011, Uma Chunduri wrote: >>>> >>>>> >>>>> >>>> .... >>>> >>>>> >>>>> True, privacy through SSH is overkill but strong AUTH is *critical*, I >>>>> feel: >>>>> - TCP-MD5 should not be considered (as it is any ways deprecated >>>>> and it's MD5) >>>>> - TCP-AO has only slight advantage as it has less overhead than >>>>> ipsec-AH even when >>>>> deployed with manual keys >>>>> - but it's better if it is "MUST support authentication of nodes >>>>> with TCP-AO or ipsec-AH" because >>>> >>>> Just to be sure: >>>> >>>> Did you understand the part about implementations of TCP-AO and ipsec-AH >>>> not being available at present? >>>> >>>> I.e., you recognize this forces a delay in implementation of the protocol >>>> (and accept the consequent impact on deployment of the RPKI)? >>>> >>>> [Uma] Yes, I did. Even though operators don't like ipsec-AH today, it >>>> is still deployed for OSPFv3 protection as that (of course now there are >>>> other drafts to mitigate complexity with reasonable trade-off). >>>> >>> >>> So, speaking as just another guy on the bus here... it's not about 'dont >>> like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC" >>> >>> Keep in mind that a router is not a generic CPU + intel ethernet PCI card, >>> and often the OS on it is optomized for a particular duty, in large iron >>> routers it's NOT ipsec. >>> >>>> Problem with MD5 is, it can present the *weakest* link for the whole RPKI >>>> infa. >>>> At least new infrastructure like RPKI should avoid deprecated stuff. >>> >>> exactly how is MD5 the weakest link here? some particular words about the >>> threat model + ability to subvert a running session which ships a few >>> megabytes/minute around would be in order here. >>> >>> [Uma] >>> >>> 1. Wang, X., H. Yu, "How to break MD5 and other hash >>> functions", Proc. IACR Eurocrypt 2005, Denmark >> >> depends on creating 2 items to hash I believe? shows that if you do >> the right thing for 2 very large items you create you can get a >> collision in some instances. not picking random bits off the wire, not >> relevant, move on. >> >>> 2. RFC 4270 >> >> talks about the above, not relevant. >> >>> >>> 3. long back even OSPF, ISIS etc.. moved away from MD5 >> >> fear, uncertainty, doubt. >> >> we aren't talking about a permanent use of md5, we're talking about: >> Use something that provides authentication/assurance NOW so we can >> move forward, knowing full well we'll change to the better/required >> solution when it's available in the right places. >> >> There's not a single AO implementation available today... it's DOA >> until there is. (frankly it's kind of a failure that there aren't >> widely deployed implementations of this... given all the time to >> invent it and all) >> >>> 4. ... >>> >>> For that matter SHA1 is getting deprecated >>> http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation >>> >> >> again, not relevant. >> >> please find something relevant that's not just fear mongering. Or, >> alternately, find implementations of AO in the servers and routers >> that matter. (if there are AO implementations w00t! we all win, until >> then we spin) >> >> -chris >> <regular guy socks==on> >> >>> >>> Getting public keys from a server with a deprecated auth mechanism to >>> verify RSA signature? >>> it's obscure..and not sure why it's not considered weak. >>> Well, one can still use and design systems around this if this is still >>> seen adequate. >>> >>> -Uma >>> >>> >>> >>> >>> -chris >>> <just a guy> >>> >>>> -Uma >>>> >>>> >>>> --Sandy, speaking as wg co-chair >>>> >>>> >>>>> as both support >>>>> - strong auth algos >>>>> - algo agility >>>>> - can be deployed with manual and auto key management >>>>> (auto key probably required eventually, once with lot of >>>>> connections at >>>>> cache/global RPKI/server side and for automatic key >>>>> changes periodically) >>>>> - key changes for existing sessions >>>>> >>>>> One would get flexibility with this. >>>>> Also Section 7 (page 16) >>>>> "It is assumed that the router and cache have exchanged keys out of >>>>> band by some reasonably secured means" >>>>> This will be still applicable but only if TCP-AO/ipsce-AH are deployed >>>>> with manual keys. >>>>> >>>>> 2 cents, >>>>> -Uma >>>>> >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>> >>>> _______________________________________________ >>>> sidr mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >>> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
