In message <7c362eef9c7896468b36c9b79200d8350cfd0de...@inbansxchmbsa1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > OSPFers, > > Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? > > Cheers, Manav
Hesitant to say "me too" again for S/N reasons, but ... yes/agree Someone needs to write up the details though. (and Manav seems willing to volunteer). Curtis > > -----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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
