[OSPF] Regarding the replay attacks in routing protocols

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 31 March 2011 02:47 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BA33A6BF1; Wed, 30 Mar 2011 19:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.715
X-Spam-Level:
X-Spam-Status: No, score=-6.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtgxtIaw0kOp; Wed, 30 Mar 2011 19:47:33 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C65733A6BF0; Wed, 30 Mar 2011 19:47:33 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V2n9Ir007944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 21:49:11 -0500 (CDT)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V2n8kn008636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 08:19:08 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 31 Mar 2011 08:19:08 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "karp@ietf.org" <karp@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
Date: Thu, 31 Mar 2011 08:19:04 +0530
Thread-Topic: Regarding the replay attacks in routing protocols
Thread-Index: AcvvTjK0vpHOKISuSFGYYUQpZJJEdA==
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B6A@INBANSXCHMBSA1.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: [OSPF] Regarding the replay attacks in routing protocols
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 02:47:35 -0000

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