Re: Attacking BFD with NULL auth

Reshad Rahman <reshad@yahoo.com> Tue, 06 February 2024 16:51 UTC

Return-Path: <reshad@yahoo.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 292C6C151080 for <rtg-bfd@ietfa.amsl.com>; Tue, 6 Feb 2024 08:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtaMvJiYVSPA for <rtg-bfd@ietfa.amsl.com>; Tue, 6 Feb 2024 08:51:53 -0800 (PST)
Received: from sonic318-26.consmr.mail.bf2.yahoo.com (sonic318-26.consmr.mail.bf2.yahoo.com [74.6.135.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4723C14F61B for <rtg-bfd@ietf.org>; Tue, 6 Feb 2024 08:51:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707238311; bh=lsiHHNAKnimljQDRwslrM6RCBJ2ScUjHTwnlXk4iiMQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=osvpDy0Y9G10XTscM0uTIDerzcu2fie2JdmsKZr59QU4P2mqW3fiQRBCsppku3dqdLlMF7BoGUutRx/6FYwF/0+4PYobg4TxYaCA445qIMcYglVERymY2T65sR9Bg+Oo51fBpSD5h6Joyv2ttoJbeJAjIGmYJ2XWK5ykpVorqYiN2BsPWeIbJ+U4bgSZpGQBfQbFxcAPbTjq6aJf10MmGSrZO0cHiQ7j+nWrNBHRsO6NDfE4K1K1wwTray57s5VqzMq6ejXd9XZmbRH1DsDb1kPnORf+UFkreO7Qun1iFjrvQg6ZFh/Kq4GTE852lXSEqaD4er38QeRRineeE5BrQg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1707238311; bh=/PuULVFMblOQn1B4/ENRyvEW2fJ+RmvUvMp45s+WXnR=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ot3D9s4qsTard6Ddl+T5GCnbD1xi1YVIvpCJNUpXkD2GtuD7bLJ9pi7rjLmKueOk+aHlP3wy1uLWURhGjrcABJnDxgM5pJaJLOdqjasB00vw6Prkj6aO/p4WAgjPQvDWf6URLLzIFTfFdVFTdsKCt1Rx79t2u4J86Dka59XEfRttQEKlwUhEuryROzzGdFoMDucP7yohK/1T9e4bw/JNc4Gy6Lq2j06tfvBryODq/hiTzLdKrhrSzOS8b9gokmpcibQw/t18HncG8m9OciebGhD3gXola8f2LsGeeEZGsEGkiJlbpXsSomXXofTbKIGyCugn1o4ff+OBqSNLu0YWDg==
X-YMail-OSG: E9Us1DsVM1lofA4wS4pyv347XQ84tC4ZFgU8Kgu5G6yyUMngQqU1qmJad5_eXY5 xizgJ1GL6E3dyGP0bNisErsX1d_V.RBbhZUUawMIlx27M5SnBgp9mF_CU6kZ5r68xq99dSTDxXr9 0.4B4X9OiAyndV4KLRdvft8Hm8h3wDfzKhU7CEOXM.36Jm_GmK5yYXw1D8FmdsazkDN5U4WkTvUq m9mpTF19ksZ7hI4CTbbMkUigyDsQU.Zcz_DFwku6LJfE_dR0GiklgE7MlBY8rxCMo3nijBOGNBsv mhuCKbe1Ymndkx_KMweWkUc3rvsqSOwsuGmNE3gEmz53CD4IXVNOs9epO.ih4Dgi79uEaXYfLYGC Wp5zWYe71D14CJC6EtaQDf1.V64DCdDR76EkEpKe7PaZTKCIRFDIUmbY2hTJqOXRZVPdTECcZNTS tc8kGSe19tWiWFAvONaq.gBE143y7gpf3v1dndKXjR56jihb_ibxyEiQhsUKzG_bKKFk5I5oZq82 YkzK3gmaKh3dMaWL1uf1PjVyihywQROAGz_GXx7mnxt9WdXX3VlqmSw74hYyWmmSWJUnS1.ePbC9 pT54Ih0Y9ge2BcTj2lvhgZKXpFopeDvVmKp.LNiqt_GsR8Q.vNPRr0wk__QAPeRkNBEGqYNRQ1j4 IlB9wEB5RGQCWizNrg24EdXBtxgheY66jGS77cxl6RIU3iyeysYmyV5hl5wR9jvj4am1nywaYvSb ZS9YFpMSf7UV1YTfXP0E1IG07Q0rYkOnKpAfqpsa4K7NWpcs_hx94_KhECJdFvq2AVWki5KPfoNP rssOW3IGCfh_e2SB.pz9tjDHXdihHVjCIWTQYkKjNx_toxunr0t6F8mQ5YLFU3fO8NZze9hKNAuz e3rgkl..z2MhQI9tHv0UwpsNXCNwOZ9slnQziagxTsZPLWTI4eVMuKgsATzARnCV6z8bpCCuIyoJ XD2MPn8Fq4buluoPt5MujOl17cnkUCVDyLuRX_H7R.tbMv5KH5gY5Rau.j1VxMc1Jm5tzq3xFaz1 jwFFjGxFcC6iL0VRxX8RNCqNHe1imZCXqlKvDWaFsqtIMnlq4vx6DVSPPecsi3YICm4g.qYTY9_N Wv4_nkOWw1G6LFIFy0fghJxxwjG11HAHVSyudSV55pMI.tFNu_PYUnx7BUnuA2.bFz3M8o875nj6 keoBU6Q6sDExb0M7O_Ro5UL2Vd0t1srTiOG25gTS2gLdhJcJ_sUg_L_NlbmaVv7Cj1Q17T4GqvzX V49lIdQlHk1hswC8m73TQdAKBkH.8vr2Bqoe2050P.HPBy7UUyDPxOg6ToQyTduKyKlfeNpF1CUN iNh2mvzh5TVVuU.KJqE8iGNHJzqiT.U0AUBEgiZ9G7J3rhCAO0uRtOTOaplvYKGq57NNYtkeZAU6 OP5iMbnvn3eF.pvg8M.gaAWtlqGonPbLuQNcFTnsRCuh5TNfDgByjY7WH.w2QQYmyEX0BTuuiwED Cmcpu_Mz2Ve8MutU7zhP9P_VEi0K5Ie3pvQ6jdkb.yyghrbnExyXpEsMZNPLRxK8tK5YlDvMSvWh ysqaAAOrmjAJyZPoNXGibdV89b8vCFjVthSZWMgcW.VlEAR8Y44gcU53ieasOjnmP_TAMwfZTDQL 1SaO2zpEiJh0ZlINbBo2GH8rkK3rSapYLCxpp0TofVCz9n_DphncWS2dWH3K.2BLQZ20jgofnNdx LkuIcpJVYQR9tv.81AU_6F4eXE.9KXhBmKvWh4qVtf14FOE1YnCj6IoZlhXI7PodasE.fjMHyitO u4V7nImqYAuQREP78TMHZh8RJSQ6TjW0ywU5MSM03lKnTOG9Yo5voWaWouXVi.u6UlSvQV9lP.2_ SW28m7Nv2Rlhrmm7m9EL_Iw3_B20DeatQKNohr7WOIPRM4eoiMaSMr65EIlzTr.DNr6mXfdCzQes wa8S_WCdl90ETG.Vp1hjxuZnTh56GwK6.oIUL1jHE74KMnDlw0D3hZLjpb7UAEgRNQfgfAE_CtFl acDt2KcumsNzMHzLnMLwxz2bTMMJhg0R0pj9qFonI2NxanryHO8DMXzpCsT5eemq1hTywKAI8Vip RuDCtyGN3MnQvEaKm4i760TBWkodm0OqzP_inV6fs.HivOg1fM8GedpfM9JUQPDXR2GutrLt60Ck gqbw3_U3C8XbxYJpcidIpEDNZL7ghGD7yLdrD8ozhJm6Z71wSSEOZTx1t.dCIXxoUlWprVFP3KVT Y8lNe2ZXJAGuYWVENQxPnKEA5iV5TcQfDutXK0WtrnTbXvsmAUxyeI3F_GfxTxLKlXCd.XBydzzK 5H0VYVWuXdmMuxhLch.uf.btjUROetextxBmDRiANW7hYQiH_qcQ1XA--
X-Sonic-MF: <reshad@yahoo.com>
X-Sonic-ID: 187150f6-21de-450d-b12e-21cc01def3a9
Received: from sonic.gate.mail.ne1.yahoo.com by sonic318.consmr.mail.bf2.yahoo.com with HTTP; Tue, 6 Feb 2024 16:51:51 +0000
Date: Tue, 06 Feb 2024 16:51:49 +0000
From: Reshad Rahman <reshad@yahoo.com>
Reply-To: Reshad Rahman <reshad@yahoo.com>
To: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>
Message-ID: <189423773.3335904.1707238309952@mail.yahoo.com>
In-Reply-To: <336054A1-4729-446B-BE73-832650B75BED@pfrc.org>
References: <336054A1-4729-446B-BE73-832650B75BED@pfrc.org>
Subject: Re: Attacking BFD with NULL auth
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3335903_1970626496.1707238309951"
X-Mailer: WebService/1.1.22046 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/8_kvNaRRAhp1uoZ2xabWvr1Aca4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 06 Feb 2024 16:51:55 -0000

 Jeff, you mention below that NULL auth with sequence numbers is impractical to use for optimizing authentication. I agree that NULL auth doesn't help with an active attacker, but it still gives protection against "random" attacks? ISAAC works for active attacks but I don't understand why no-auth still works, no-auth is weaker than NULL auth: you don't need to be an active attacker to knock over a session with no-auth?
Regards,Reshad.
    On Tuesday, February 6, 2024, 08:56:44 AM EST, Jeffrey Haas <jhaas@pfrc.org> wrote:  
 
 My thought over first cup of caffeine for the morning: You can have an active attacker attack a session using NULL auth and knock over a BFD session.  This is counter to the usual "silly" attack of keeping BFD Up.

Presume the session is in the Up state between A and B and using NULL auth.  The current expected sequence number at A from B is 100.

An active attacker, seeing that 100 is the sequence number, spoofs packets rapidly in order 101..200.

Sequence number procedures are, tersely, "accept the larger sequence number as long as it's bigger".  Presume that some portion of that spray of packets gets through and moves the sequence number > 100 + 3 before B would have sent sequence 101.

B then continues happily sending the meticulously increasing packets, 101, 102, 103.  These packets are discarded because the sequence number is under the "last seen" sequence number.

The session drops.

I don't believe there is any mitigation against this attack in NULL auth.

The impacts of this, if so:
1. NULL auth and using the sequence numbers becomes impractical to use for optimizing authentication procedures.  ISAAC and no-auth still work.  
2. BFD stability really wants that increasing sequence number.  This leads to using either meticulous types from the strong authentication mechanisms, or ISAAC.

Counter observation 1: Stability doesn't really care about the sequence numbers from a security standpoint, just a dropped packet standpoint.  The attack against stability if the sequence numbers aren't used for authentication of the session to drop the session is to trigger an "unstable" event and whatever trigger might be tied to that mechanism as a client.

Counter observation 2: If the sequence numbers are ignored as a mechanism for taking the session down, you can't use it to prevent PITM attacks, but it's no worse than no-auth.  The periodic strong authentication becomes more important.


-- Jeff