----- Original Message ----- From: "Joe Touch" <[email protected]> To: "Christopher Morrow" <[email protected]> Cc: "sidr wg list" <[email protected]> Sent: Friday, April 22, 2011 7:27 AM > 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)
Joe I think that the point is not that it is or is not a BGP connection but that security for BGP was predicated on the assumption that the TCP connection would be short in terms of hops, ie none, and it was that that made a less stringent approach to security acceptable, one that would not be acceptable for an Internet wide access for - say - a Web site. What I am missing is not whether or not this is BGP, but whether or not the connection will have the properties of BGP, of being very short. My suspicion is that the data will be coming from all over the place, Internet-wide (as with CRL) and so the security should be Web-like and not BGP-like; ie TCP-AO will not do. Tom Petch > > Joe > > > > > > -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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
