On Fri, Apr 22, 2011 at 1:27 AM, Joe Touch <[email protected]> wrote: > > > On Apr 21, 2011, at 10:10 PM, Christopher Morrow <[email protected]> > wrote: > >> On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch <[email protected]> wrote: >>> >>> >>> On Apr 21, 2011, at 7:45 PM, Christopher Morrow <[email protected]> >>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>> >>> > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
