OSPFers, Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT?
Cheers, Manav > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bhatia, Manav (Manav) > Sent: Thursday, April 14, 2011 5.18 AM > To: [email protected] > Subject: [karp] Using dynamically derived Traffic Keys for > Routing Protocols > > Hi, > > Instead of using the pre shared key (PSK) in manual keying > for all packets the routing protocols could use a traffic key > that's derived from the PSK using some key derivation > function. Each side could announce a random number (a nonce) > and the KDF could mix this with the PSK to derive the traffic > key per session. Benefits of this approach: > > o Key rollover becomes very easy as it's a local decision now > requiring now co-ordination with our peers. Each side can > generate a new nonce and all others recompute the traffic key > based on the new nonce value. Attackers cant inject packets > with spurious nonces as this packet will be protected using > the traffic key based on the nonce that others have sent. > > o Avoids inter-session replay attacks without involving non > volatile memory as each router will use a different nonce > upon booting up. > > In OSPF the nonce could be carried in the HELLO packets. > There could be bit carried in the HELLOs which would indicate > that the Hello is currently using the long lived key (or the > PSK). The receiver upon receiving this would authenticate the > packet using the PSK and would use the KDF to derive the > traffic key. The KDF would mix the nonce with the PSK in some > deterministic fashion. The receiver uses the derived traffic > key for signing all subsequent OSPF packets and would > indicate this by setting some bit (which says using traffic > key). It will also include its own nonce. The original sender > now uses the nonce that it receives and starts using the > traffic key derived from this nonce for all subsequent > packets. For a key rollover, the senders just have to choose > a new nonce value. This can be done as frequently as desired > and requires no manual intervention. > > Does this sound as going in the right direction? > > Cheers, Manav > > -- > Manav Bhatia, > Service Router Product Group (SRPG) > Alcatel-Lucent, India > _______________________________________________ > karp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
