1. IS-IS ESN TLV draft-chunduri-isis-extended-sequence-no-tlv-01 Uma Chunduri, Wenhu Lu, Albert Tian Ericsson Inc. Naiming Shen Cisco Systems, Inc. IETF 83, Paris, France March 26-30, 2012 83 rd IETF @ Paris 1

2. Problem Briefly described in Sec. considerations section of [RFC5304] Sec 3.1 - This mechanism does not prevent replay attacks; however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information. [RFC5310] Sec 4 - The mechanism detailed in this document does not protect IS-IS against replay attacks. An adversary could in theory replay old IIHs and bring down the adjacency [CRYPTO]…. OPSec WG [RFC6039] Sec 4.2 - IS-IS does not provide a sequence number. IS-IS packets are vulnerable to replay attacks; any packet can be replayed at any point of time. So long as the keys used are the same, protocol elements that would not be rejected will affect existing sessions. 2 83 rd IETF @ Paris IS-IS ESN TLV

3. IS-IS Gap analysis draft presented in KARP WG (Taipei-IETF82) per RFC 6518 - KARP WG design guide Karp Threat Requirements Also discussed the replay threat in various broadcast networks and also this particular (ESN TLV) draft KARP WG asked for applicability statement in the draft IS-IS is not only restricted to few Tier-1 ISP backbones but..has been adopted widely in various L2 and L3 routing deployment of the data centers for critical business operations. Captured the same in current 01 version 3 83 rd IETF @ Paris

4. Problem?? Replay attacks with IS-IS protocol messages to create churn in the broadcast networks 4 83 rd IETF @ Paris

5. How? IIH ADJ flaps in broadcast by replying empty neighbor list (TLV 6) SNP Can mount DoS attacks by sending old CSNP/PSNP packets 5 83 rd IETF @ Paris

6. How? (Contd.) LSP Already protected from intra session replay attacks with header seq. no But still vulnerable for inter session attacks Les Ginsberg has raised few questions/scenarios how this is possible (in IS-IS WG) Issue is acked. but felt impact is smaller (as new Seq. is originated eventually) and claimed, its not repeatable for multiple times How ever.. both the above are subjective as by that time all the nodes in the network see the churn (impact also depends on what info is missing in the replayed LSPs) this can be done for multiple nodes in the network which has area/domain wide impact every time 6 83 rd IETF @ Paris

7. ESN TLV (Type – IANA TBD) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Session Sequence Number (High Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Session Sequence Number (Low Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Packet Sequence Number (32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESSN Starts with non-zero and incremented in PSN wrap scenario, session refresh, cold restarts etc.. PSN Incremented per packet (only applicable for IIH and SNPs) 7 83 rd IETF @ Paris

8. Processing IIH Maintained per interface (per level) and can be stored in ADJ state Tx: ESSN can be encoded as 64-bit time or boot count, PSN starts with 1 and increases per packet Rx: ESSN same or higher that the stored vale in ADJ and PSN is higher LSP If present ESSN encoding/processing is similar to IIH No changes to current header Sequence no processing CSNP/PSNP Based on Broadcast or P2P network encoding and processing similar to above (refer draft for further details) 8 83 rd IETF @ Paris

9. ESSN encoding - Guidelines as described in Appendix A REQ: It should be ever increasing quantity 64-bit system timestamp encoding as of NTP long format (MUST not go to previous value after cold restart) Battery backed RTC Boot count in non-volatile storage Similar to proposed in OSPF non-volatile storage: if repaired, keys MUST be changed to avoid the attacks 9 83 rd IETF @ Paris

10. KARP IS-IS security gap analysis draft-chunduri-karp-is-is-gap-analysis-01 Presented in KARP WG (IETF82) - We welcome feedback 83 rd IETF @PARIS 10

11. Questions & Comments? Thank You! 83rd IETF @PARIS 11