Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Christopher Morrow <[e-mail]>]

On Sat, Jun 4, 2011 at 10:02 AM, Joe Touch <[e-mail]> 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 <[e-mail]> wrote:
>
>> On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri <[e-mail]> wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Christopher Morrow
>>> Sent: Friday, June 03, 2011 6:11 PM
>>> To: Uma Chunduri
>>> Cc: Sandra Murphy; [e-mail]; [e-mail]
>>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>>>
>>> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <[e-mail]> wrote:
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sandra Murphy [mailto:[e-mail]]
>>>> Sent: Friday, June 03, 2011 1:43 PM
>>>> To: Uma Chunduri
>>>> Cc: [e-mail]; Sean Turner; [e-mail]
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>>>
>>>> _______________________________________________
>>>> sidr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>>
>>>
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>