Security aspects with S-BFD

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 07 November 2013 16:49 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2B921E812B for <rtg-bfd@ietfa.amsl.com>; Thu, 7 Nov 2013 08:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNUMtOPw9IFL for <rtg-bfd@ietfa.amsl.com>; Thu, 7 Nov 2013 08:49:39 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2221E8158 for <rtg-bfd@ietf.org>; Thu, 7 Nov 2013 08:48:54 -0800 (PST)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA7GmpMg006016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <rtg-bfd@ietf.org>; Thu, 7 Nov 2013 10:48:52 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id rA7GmpWP030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtg-bfd@ietf.org>; Thu, 7 Nov 2013 11:48:51 -0500
Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 7 Nov 2013 11:48:51 -0500
Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 00:48:48 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Security aspects with S-BFD
Thread-Topic: Security aspects with S-BFD
Thread-Index: Ac7b2ToBrFn7tnaZR4yTSVGAJsb+Gw==
Date: Thu, 07 Nov 2013 16:48:47 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C32E4FACB1@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.253.19.18]
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.37
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 16:49:52 -0000

Hi,

S-BFD describes the reflector sessions which raises interesting security considerations.

Since the reflector sessions are stateless (that's one of the biggest advantages) it's impossible for the reflector to keep track of the sequence number that its heard from its peers. This means, that the reflector is susceptible to both inter-session and intra-session replay attacks. We had a discussion internally amongst the co-authors and had the following proposal that we wanted to vet before the WG members.

Would like to hear the WGs opinion on this.

1. The Initiator picks up a crypto sequence number depending upon the authentication mode that its using (meticulous or non meticulous). It sends a packet to the Reflector with this seq num.

2. The reflector maintains no session state and hence does not look at the crypto sequence number before accepting the packet. It looks at the Key ID (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can do it based on its own database where it maps the neighbor to the key iD) and verifies the authentication data. If everything looks good, it processes the packet. 

3. When responding the Reflector needs to compute the Authentication data. It uses the same sequence number that it received in the S-BFD packet that it is responding to. It knows the Key ID, and thus the SA. It computes the authentication data and sends the S-BFD packet out.

4. The Initiator receives the response from the Reflector. It only accepts the S-BFD packet if it either comes with the same sequence number as it had sent or its within the window that it finds acceptable (described in detail in Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)

Benefits of this scheme.

1. Reflectors continue to remain stateless despite using security.

2. Reflectors are not susceptible to replay attacks as they always respond to S-BFD packets irrespective of the sequence number carried.

3. An attacker cannot forge packets from the Reflector since the Initiator will only accept S-BFD packets that come with the sequence number that it had originally used when sending the S-BFD packet.

Drawbacks of this scheme.

1. Reflectors are susceptible to DoS attacks since they respond to all incoming S-BFD packets. This gets worse when cryptography is used as the work load drastically increases as security is employed.

Cheers, Manav