Transcript PPT Version

OSPFv3 Automated Group
Keying Requirements
Michael Barnes, [email protected]
Liu Ya, [email protected]
Russ White, [email protected]
Brian Weis, [email protected]
IETF #68
1
Background
• RFC4552 defines how to provide
authentication/confidentiality to OSPFv3 using
IPsec.
– For broadcast interfaces, a group SA is used to
provide “one to many” security.
– Manual Keying is the required key method. It has
limited security and scalabilty.
• Standard GKM (group key management)
protocols are available.
– So, it is feasible to implement automated group
keying for OSPFv3 using GKM protocols.
2
Aspects to think about …
• ‘Chickens and Eggs’ issue:
– GKM protocols (e.g., GSAKMP, GDOI) are based on
client/server architecture. Routes must be available before group
members get group SA from key server.
– Routes are built by OSPFv3 routers. The building process MUST
be protected.
– The conflicting of preconditions occurs in case of router
joining/restarting, route flap, etc.
• Single point of key server failure
– It’s a common issue of C/S architecture.
• Inter-network multicast issue:
– A key server may serve a number of group members that are in
different broadcast network.
– It is better for the key server to push rekeying messages to its
members using IP multicast .
– However, inter-network multicast is seldom deployed.
3
Using OSPF in the solution?
• OSPF flooding could be used to assist with rekeying,
but would we want to do that?
(I doubt it.)
• Any other way that OSPF could be used in the
solution?
4
Thanks!
5