Subject: [Isis-wg] New version of the anti-replay draft.

From: Alex Zinin <[email-masked]>
Date: Fri, 3 Aug 2001 04:12:41 -0700

Folks,

 Below is the new version of the document. This includes
 type-133 sub-TLV format as suggested by Hannes and Tony, the
 CSN sub-TLV (GenID + SN), separate for each packet type,
 the Key ID sub-TLV, and using link-level keys for SNPs.
 This seems to be a good enough approximation to start
 the discussion.

 I'll also do some slides in London.

-- 
Alex Zinin

Network Working Group                                         Alex Zinin
Internet Draft                                             Nexsi Systems
Expiration Date: February 2002                               August 2001
File name: draft-zinin-isis-auth-anti-replay-00.txt

                  Protecting ISIS from replay attacks

                draft-zinin-isis-auth-anti-replay-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes an additional mechanism for ISIS
   cryptographic authentication that protects ISIS networks from simple
   packet replay attacks.

1 Motivation

   The cryptographic authentication mechanism for [ISIS], described in
   [HMAC] provides basic authentication functionality sufficient for the
   majority of situations. However, this mechanism does not protect ISIS
   networks from the replay attacks that can be performed by the
   attacker if it has direct access to a broadcast segment within an
   ISIS domain.

Zinin                                                           [Page 1]

INTERNET DRAFT     Protecting ISIS from replay attacks       August 2001

   Because the mechanism described in [HMAC] does not include the notion
   of "cryptographic sequence number", an attacker can easily replay
   previously recorded ISIS packets.

   Examples of these attacks include replaying an empty (listing no
   neighbor IS) IIH packets and thus causing routers on the segment to
   destroy the adjacencies with a specific router, replaying CSNP
   packets and thus artificially attracting ISIS traffic (LSPs) to the
   segment's DIS, and so on. When used periodically, these attacks can
   cause global instability in an ISIS domain.

   This document defines a simple mechanism, similar to the one proposed
   for the OSPF protocol in [ETIENNE], to protect an ISIS network from
   the replay attacks by introducing Cryptographic Sequence Number and
   Generation ID into ISIS packets. The method is compatible with the
   existing implementations of [HMAC].  In addition to the Cryptographic
   Sequence Numbers, the document defines transmission of the
   cryptographic Key IDs that help routers identify the key to be used
   for authentication when multiple keys are active during the key
   transition period.

   It must be noted that the described mechanism does not attempt to
   increase purely cryptographic strength of the ISIS authentication
   mechanism, but rather addresses the problems inside [HMAC].

2 Proposed Solution

   Both the Cryptographic Sequence Number and the key ID are introduced
   into the ISIS packets as sub-TLVs of the TLV type-133. The type-133
   TLV is considered to be a part of text T while calculating the HMAC-
   MD5 digest as defined in [HMAC] (i.e., the type-133 TLV is covered by
   the digest to prevent spoofing of the values inside the TLV).  Sub-
   TLVs are formatted as described in [ISIS-TE]. This document defines
   the following sub-TLVs:

      Type  Length (octets)  Name
        1        8           Cryptographic Sequence Number (CSN)
        2        2           Cryptographic Key ID (CKID)

   [HMAC] specifies that ISIS Sequence Number Packets should be
   authenticated using the area-level authentication key. In order to
   prevent attacks based on replaying packets recorded on a different
   network segment, the implementations are encouraged to support SNP
   authentication using the link-level key. Note that this requires
   proper configuration on all routers attached to a network segment.

   This version of the document does not specify the use of the CSN sub-
   TLV in ISIS LSPs. Instead, the existing LSP Sequence Number and

Zinin                                                           [Page 2]

INTERNET DRAFT     Protecting ISIS from replay attacks       August 2001

   associated LSP processing procedures are used, with the reservations
   described in [HMAC]. Note, however, that CKID sub-TLV can be used in
   all ISIS packets, including LSPs.

   Implementations not supporting described extensions should ignore the
   TLVs defined herein.

 2.1 Cryptographic Sequence Number sub-TLV.

   The CSN sub-TLV contains the following data:

       2 octets of Generation ID
       4 octets of Sequence Number

   A single instance of the Generation ID is maintained by each ISIS
   process, initially set to zero, and incremented each time the ISIS
   module is restarted (e.g., when the router reboots).  The Generation
   ID prevents replay attacks using recorded packets from the previous
   incarnation of the ISIS process. This document does not specify the
   exact method of storing the value of the Generation ID across the
   ISIS module or router restarts, however, it is anticipated that the
   implementations will use some type of non-volatile memory (flash
   memory, hard disk, etc.)  for this purpose.

   Each ISIS module also maintains a single instance of the Sequence
   Number for each {interface, packet-type} combination. The Sequence
   Number is initially set to zero, and incremented each time a packet
   of the associated type is sent on the associated interface.
   Maintaining separate Sequence Numbers for different packet types
   allows the receiving router to diverge the packet processing paths
   without affecting the authentication properties of the protocol.

   The document does not specify the procedure for the situations where
   the Sequence Number for a specific {interface, packet-type}
   combination reaches its maximum. A possible approach would be to
   increase the Generation ID on the router and reset Sequence Number
   values on all interfaces.

 2.1.1 Sending ISIS Packets with CSN sub-TLV

   When constructing an ISIS packet authenticated using [HMAC], the
   router may include the CSN sub-TLV in the type-133 TLV.  If the TLV
   is included, it should be considered a part of the text for the
   digest calculation. After the packet has been sent, the
   implementation must increase the associated Sequence Number.

 2.1.2 Receiving ISIS Packets with CSN sub-TLV

Zinin                                                           [Page 3]

INTERNET DRAFT     Protecting ISIS from replay attacks       August 2001

   ISIS implementations supporting described extensions should maintain
   the received Generation ID and Sequence Number for each {interface,
   neighbor, packet-type} combination. These values should be set to
   zero when a new neighbor data structure is created.

   When receiving an HMAC-authenticated ISIS packet with a type-133 TLV,
   the router performs the following checks (if the packet is not HMAC-
   authenticated, but contains the type-133 TLV, the type-133 TLV should
   be ignored).

    1. If the CSN sub-TLV is present, compare the values found
       in the TLV with the values in the neighbor data structure
       (for a specific packet type) as described below.

         a) If the received Generation ID is less than the locally
            recorded value, the packet should be ignored.

         b) Otherwise, if the received Generation ID is greater than
            the locally recorded value, the Sequence Number should
            not be checked and step d) should be performed.

         c) Otherwise, if the received Generation ID is equal to
            the locally recorded value and the received Sequence
            Number is not greater than the locally recorded value,
            the packet should be ignored.

         d) Perform the packet verification procedure as
            described in [HMAC] and update the neighbor data structure
            with the received Generation ID and Sequence Number.

    2. If the ISIS packet is authenticated using [HMAC], does not
       contain the CSN sub-TLV, and the router is configured to perform
       CSN verification on the receiving interface, the ISIS packet
       should be ignored. Otherwise (the router is not configured to
       perform CSN verification), the packet should be authenticated
       as described in [HMAC].

 2.2 Cryptographic Key ID Sub-TLV

   The CKID Sub-TLV contains the 16-bit ID of the key that was used to
   authenticate the packet. Depending on the type and level of the
   packet, the key ID identifies a specific area or link level
   authentication key when multiple keys are active at the same time.

 2.2.1 Sending Packets with CKID sub-TLV

   When constructing an HMAC-authenticated packet, a router may include
   the CKID sub-TLV in the type-133 TLV. If included, the CKID sub-TLV

Zinin                                                           [Page 4]

INTERNET DRAFT     Protecting ISIS from replay attacks       August 2001

   should contain the ID of the key that is used to authenticate the
   packet.

 2.2.2 Receiving Packets with CKID sub-TLV

   When receiving an HMAC-authenticated PDU with the CKID sub-TLV, the
   receiving router should locate the key associated with the received
   key ID and use it for the packet authentication procedure.  If the
   receiving router cannot find the key with specified ID or if the key
   is not active, the received PDU should be ignored.  If the CKID sub-
   TLV is not present in the PDU, the procedures defined in [HMAC]
   should be followed (i.e., the CKID sub-TLV does not have to be
   included for an HMAC-signed ISIS packet to be considered authentic,
   instead it gives the receiving router a "hint" about the key that
   should be used for authentication when multiple keys are present).

   This document does not specify the key management procedure, however,
   the routers need to agree on the key IDs for the packets to be
   authenticated correctly.

3 Compatibility Issues

   Implementations not supporting described extensions will ignore the
   TLVs defined in this document. Also, implementations supporting the
   new TLVs will interoperate with implementation using [HMAC] only
   unless explicitly configured to perform sequence number verification,
   which is expected to be done when all routers on a segment support
   described mechanism.

4 Security issues

   This document describes a mechanism that improves security of the
   ISIS protocol.

5 Acknowledgements

   The author would like to thank Hannes Gredler, Tony Przygienda, Ran
   Atkinson, David Hudek and the rest of the ISIS working group for
   valuable feedback on this document.

6 References

   [ISIS] ISO, "Intermediate system to Intermediate system routeing
          information exchange protocol for use in conjunction with the
          Protocol for providing the Connectionless-mode Network Service
          (ISO 8473)," ISO/IEC 10589:1992.

   [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"

Zinin                                                           [Page 5]

INTERNET DRAFT     Protecting ISIS from replay attacks       August 2001

          Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.

   [ETIENNE] Jerome Etienne. "Proposal to fix OSPF cryptographic
          authentication flaws".

   [ISIS-TE] Li, T., Henk Smit. "IS-IS extensions for Traffic
          Engineering". Work in progress. June 2001. draft-ietf-isis-
          traffic-03.txt

7 Author's address

   Alex Zinin
   Nexsi Systems
   1959 Concourse Drive
   San Jose, CA 95131
   [email-masked]

Zinin                                                           [Page 6]

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Alex Zinin <[email-masked]>
Date: Fri, 3 Aug 2001 13:33:39 -0700

Folks,

 One thing that I'd like to be discussed is using CSNs in LSPs.
 The document does not specify this, but I think this needs
 attention.

 My opinion is LSP's native sequence number is not good enough
 (we lose the state when the LSP is purged, the SN space is reused
 each reload, etc.), and addressing all packet types but one does
 not make much sense since all packets are the same from the
 replaying perspective, the only difference is consequences.

 A possible approach would be (I mentioned this on the list already)
 to authenticate LSPs at the link level, i.e., using the link key
 and CSN, make sure CSNs are not taken into consideration when
 deciding which LSP is more recent, and ref_cnt the keys to make
 sure they're not freed when they become inactive, or ISIS is disabled
 on the interface (or the interface is removed), but there are LSPs
 that still need the key for periodic verification (btw, this part is
 not spelled out in HMAC either).

 Comments are welcome.

-- 
Alex Zinin