So basically the problem is that: - routers don't all support IPsec for the control plane
- servers don't yet implement AO I repeat that there's a known solution that is already being used for BGP: Use AO if available Use MD5 in the meantime Yes, servers will support AO, if for no other reason than they support BGP and MD5 now. 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
