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

[Joe Touch <[e-mail]>]

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. 

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