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