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
