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