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

[Christopher Morrow <[e-mail]>]

On Fri, Apr 22, 2011 at 1:27 AM, Joe Touch <[e-mail]> wrote:
>
>
> On Apr 21, 2011, at 10:10 PM, Christopher Morrow <[e-mail]> wrote:
>
>> On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch <[e-mail]> wrote:
>>>
>>>
>>> On Apr 21, 2011, at 7:45 PM, Christopher Morrow <[e-mail]> wrote:
>>>
>>>> So.. round and round the rosemary bush we go, still we have no actual
>>>> things that run actual tcp-ao, so given that can we either:
>>>>
>>>> 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later
>>>> point to say that AO is a MUST and remove md5
>>>> 2) move this doc along the path
>>>> 3) get implementations of the protocol today to start using md5
>>>
>>> You could instead do what the TCP-AO rfc recommends for apps like BGP:
>>>
>>> - MUST support TCP-AO
>>> - MAY also support TCP MD5 for backward compatibility
>>>
>>> This avoids reinventing an answer for BGP caches and just applies the *current* advice for BGP in general.
>>>
>>
>> bgp cache is not bgp... it's really just a random tcp session from a
>> router to a thing some where else.
>>
>> (does that change your proposed above?)
>
> Nope. (and I was aware it isn't a BGP protocol connection)

awesome, was a tad worried your quote was specific to bgp... a
loophole so to speak.

>>
>> -Chris
>>
>>> Joe
>>>
>>>
>>>>
>>>> -chris
>>>> (co-chair-toe-socks-on)
>>>>
>>>> On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> On 4/20/2011 5:19 PM, Brian Weis wrote:
>>>>>>
>>>>>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/11/2011 12:49 PM, Stephen Kent wrote:
>>>>>>>>
>>>>>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote:
>>>>>>>>>
>>>>>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote:
>>>>>>>>>
>>>>>>>>>>> Getting a new application (such as the rtr protocol)
>>>>>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir
>>>>>>>>>>> review and then the Security ADs just won't happen. The
>>>>>>>>>>> only exception I can think of is if there were no possible
>>>>>>>>>>> alternatives, and that's obviously not the case here.
>>>>>>>>>>
>>>>>>>>>> with AO not implemented on any servers, routers not having
>>>>>>>>>> ssh libraries, and this being a server to router protocol,
>>>>>>>>>> what are the alternatives?
>>>>>>>>>>
>>>>>>>>>> randy
>>>>>>>>>
>>>>>>>>> I'm surprised IPsec hasn't been mentioned in this thread ...
>>>>>>>>> was it previously discussed and rejected? Correct me if I'm
>>>>>>>>> wrong, but I believe it's common for BGP routers to support
>>>>>>>>> IPsec and servers definitely support IPsec. On the router side,
>>>>>>>>> one or two IPsec sessions to servers should not be a burden.
>>>>>>>>> I'm less sure of the server IPsec scaling properties, but I
>>>>>>>>> would expect a LINUX or BSD kernel to have the scaling issues
>>>>>>>>> as were discussed earlier in this thread regarding SSH but I'm
>>>>>>>>> no expert here.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>
>>>>>>>> A few years ago we were told by vendors that many router
>>>>>>>> implementations of IPsec were available only to traffic passing
>>>>>>>> through a router, not to the control plane terminating in a
>>>>>>>> router. Unless that has changed, IPsec is not a good candidate
>>>>>>>> here.
>>>>>>>
>>>>>>> FWIW, that was an artifact of the IPsec requirements for routers.
>>>>>>> 4301 has the following requirements:
>>>>>>>
>>>>>>> (end sec 4.1, RFC 4301): In summary,
>>>>>>>
>>>>>>> a) A host implementation of IPsec MUST support both transport and
>>>>>>> tunnel mode.  This is true for native, BITS, and BITW
>>>>>>> implementations for hosts.
>>>>>>>
>>>>>>> b) A security gateway MUST support tunnel mode and MAY support
>>>>>>> transport mode.  If it supports transport mode, that should be used
>>>>>>> only when the security gateway is acting as a host, e.g., for
>>>>>>> network management, or to provide security between two intermediate
>>>>>>> systems along a path.
>>>>>>>
>>>>>>> A gateway acts as a host for all its routing protocol connections,
>>>>>>> and thus its control plane should have to comply with (a).
>>>>>>>
>>>>>>> I agree, that's why IPsec isn't a good choice to protect BGP, but
>>>>>>> we sort of created that situation in 4301, AFAICT.
>>>>>>>
>>>>>>> Joe
>>>>>>
>>>>>> I won't quibble with that argument as far as protecting BGP. But for
>>>>>> the "router-to-server" protocol described by this draft is actually
>>>>>> acting as a host for the exchange.
>>>>>
>>>>> Routers act as hosts for all routing protocol exchanges; that's not unique
>>>>> to the router-server exchange.
>>>>>
>>>>>> There are more router IPsec implementations that can protect the
>>>>>> control plane now, and meeting the requirements above would likely be
>>>>>> doable.
>>>>>
>>>>> There are other potential reasons why IPsec may or may not be the best
>>>>> choice, but I don't much care whether IPsec or TCP-AO is used; those are the
>>>>> appropriate choices if you care that the transport protocol is protected.
>>>>>
>>>>> Joe
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sidr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>>>
>>>
>