Re: [sidr] WGLC draft-sidr-rpki-rtr

On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:
>
>
> -----Original Message-----
> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com]
> Sent: Friday, June 03, 2011 1:43 PM
> To: Uma Chunduri
> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie
> 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
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>