Hi, I would urge the members of KARP WG to go through the two anti-replay mechanisms described in http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-03
One extends the current sequence number space from 32 bits to 64 bits, where the most significant 32 bits indicate the number of times the router has cold booted. This value can be fetched from the non-volatile memory, flash or some remote server (which may also possibly store the image, startup configs, etc). This value would be generic and we envisage all the other routing and signaling protocols using this in future. Thus BFD, LDP, etc can extend their crypto sequence space and use this value as the most significant 32 bits. The second entails a session ID that's maintained for each session and a nonce that guarantees that you are speaking to a live router. The session ID needs to be carried around in the protocol packets so that everyone knows the right context. The former is patently easier to implement. It requires no change on the receiving side. It requires very little change on the sending side and specifically the protocol machinery. For extremely low end devices (in the near future when small sensor devices may run OSPF to discover each other) that do not have nvram or cannot store information on some remote device we could fall back to the second solution, or decide not to provide an inter-session replay attack protection mechanism. Alternately, we could progress both the solutions and let the market decide which solution gains widespread usage. I am guessing that it will be the former because of its simplistic design. I thus propose to split the current draft into two where the base document describes the boot count and the other that explains the Session ID and Nonces. We already have a generic draft draft-bhz-karp-inter-session-replay-00 that will be presented in KARP tomorrow. Once this is accepted as a WG item other protocols (OSPF, BFD, LDP, etc) can refer to this and extend their sequence space to prevent against inter-session replay attacks. We already have an OSPF document draft-bhatia-karp-ospf-ip-layer-protection-03 that has been extensively discussed on the mailing lists and we can trim it significantly if we just provide reference to the above KARP document. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
