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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
