1 OSPFv3 Automated Group Keying Requirements draft-liu-ospfv3-automated-keying-req-01.txt Ya Liu, Russ White, Brian Weis, Michael Barnes, IETF 69, 22th Jul 2007, Chicago

2 Problem Statement GSA (Group SA) is used to provide the multicast security for OSPFv3 broadcast interfaces, e.g., Ethernet interfaces, to achieve the best scalability. However, only Manual Keying method is recommended. This method is neither scalable nor secure. –Please refer to RFC4552 for more details. On the other hand, it is feasible to implement automated group keying for OSPFv3 IPsec using standard MSEC GKM protocols. –Please refer to IETF MSEC WG for more details. IETF 69, 22th Jul 2007, Chicago

3 Aspects to Think About … Common requirements include authorizations & authentication of routers, secure distribution of GSA, storing capability of GSA context, etc. The most important issue is how to set up the GC/KS. –MSEC GKM protocols, such as GSAKMP and GDOI, are based on a client/server model. This means these protocols rely on reachability between clients and servers for the clients to obtain the group SA from the key server. In this case, the GKM is providing protection for OSPF, which is an essential component in providing reachability between the clients and servers. Hence, the client/server model breaks down in this situation. –To overcome this problem, the group SA must be locally available to each group member (each OSPFv3 router). –Possible deployment scenarios and their specific requirements are presented in following slides. IETF 69, 22th Jul 2007, Chicago

4 Scenario 1: Decentralized Physical GCKSs A physical GCKS is deployed on every multicast network, and provides group keying service for only its local neighbors. Issues: –It is cost expensive. –It suffers from single point of GCKS failure. –It is hard to manage. –It suffers from new joiner issue. GCKS IETF 69, 22th Jul 2007, Chicago

5 Scenario 2: Decentralized Logical GCKSs The GCKS is hosted by a router and provides group keying service for only its local neighbors. Issues: –It is hard to manage. –A GCKS selection mechanism is necessary here. –Authentication & authorization of GCKS. –It suffers from new joiner issue. GCKS IETF 69, 22th Jul 2007, Chicago

6 Scenario 3: Decentralized KSs, Centralized GC The logical KS is hosted by a router and provides group keying service for only its local neighbors. A single GC (Group Controller) is used for pushing policy and authorization to each KS Issues: –It suffers from bootstrapping issue. –A KS selection mechanism is necessary here. –Authorization and Authentication of KS. –It suffers from new joiner issue. GC KS IETF 69, 22th Jul 2007, Chicago

7 Scenario 4: Decentralized Delegates, Centralized GCKS Delegate is a logical role. it is deployed on every multicast network, and is responsible for relaying GSA messages between the GCKS and local group members. Issues: –It suffers from bootstrapping issue. –A delegate selection mechanism is necessary here. –Authorization and Authentication of delegate. –It suffers from new joiner issue. GCKS … Delegate IETF 69, 22th Jul 2007, Chicago

8 Next Step Need more comments and feedback from OSPF, RPSEC, and MSEC WGs. Accept this draft as a WG I-D? IETF 69, 22th Jul 2007, Chicago

9 Comments? Thanks! IETF 69, 22th Jul 2007, Chicago