Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 02 July 2020 04:13 UTC

Return-Path: <mjethanandani@gmail.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 C00EA3A0C46; Wed, 1 Jul 2020 21:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFXR1fSpSAvT; Wed, 1 Jul 2020 21:13:40 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62E83A0C3C; Wed, 1 Jul 2020 21:13:40 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id f16so1552649pjt.0; Wed, 01 Jul 2020 21:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3ohlvphNJMjdQzPvtun/tDllJ6gKZGSRgvGOxKfmeuQ=; b=h2Zs+dKYTQJUPSH4EDEMm6dHthumUErgMicqOyKyT+ySJjDJepnjD2QbPP1yPr4WNW r2zQS0xmXM3oVIiGkgr2S2IOm/zSMmVntcgfnz765HDwTUCN/C8UckbjRCy+uGOSLRz6 TTiZua2P0evEd1ykTVJ0DjY1QyazKWymt7HuyM3SnZau6ADbKajUX7IE+XZkGRjnX1yL YQjhjahoFwicHftcM3jdCm7NPWIsEcvloYSiEFFhY2B8iLmZHPTdvDXJwI7ySEZegQ1T XKbZxYzKdeF658yKTYQ9UjLeF1yHTqkgzka7lwtkyhNzPZAJ/2THeM7Ee38oKAJHroyL JqqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3ohlvphNJMjdQzPvtun/tDllJ6gKZGSRgvGOxKfmeuQ=; b=QWRMqa7peGaYqdcWu4zkFNWIONC0QYYPUwB9efakALhOBAKF/H8dYSD3EN4cbRt+zg 7nBDKQwbK2VyukbiVA5wpQxbsEPqeYYqUWMM14mA/o/fl3SV8M5zl0b5UHUtZC5HwrbR G81YZZSgQQwvdm2fgmRAu/WUdfIclMiQMvzWBD+ril5q9nGy0wJbk/+FBd3WWOJHJFyb JHdthmsTNzefhdm4JTTqXGjkU27YJgxNFrMEG43LK3yASiUIVWfm/0CcHdpZ4pN34F5d EmYKwBPBSAex9D8CqWz0zRiErZYxSNS4Ph1e9HRCCueVm7WXt6xnywO/4G7bzR9FSuDy ySTw==
X-Gm-Message-State: AOAM5318mJC/ZyJtHZV0RWTdDVtVhVWDlFl/nkl2z+shfg05c2W0ft5K iUf/dnQXDCNMff4wRvjwVAI=
X-Google-Smtp-Source: ABdhPJxzziShpjaIJVMMWVB6sFvF/sBOSJjgYt8ZEJOk3GjNYF+e9vb5585W8cWFsUj34HbyBMNAUg==
X-Received: by 2002:a17:902:b40f:: with SMTP id x15mr23450444plr.164.1593663220091; Wed, 01 Jul 2020 21:13:40 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9462:384e:168f:ba74? ([2601:647:5600:5020:9462:384e:168f:ba74]) by smtp.gmail.com with ESMTPSA id a68sm6647601pje.35.2020.07.01.21.13.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2020 21:13:38 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <8C54F0A2-0D11-4C50-B94F-19E6381365AE@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CCD64BD-E2E8-4BD3-81A5-326922D97FB8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Subject: Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication
Date: Wed, 1 Jul 2020 21:13:37 -0700
In-Reply-To: <86B2BDA3-B8BC-4ABF-A073-30844E7254FD@cisco.com>
Cc: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-optimizing-authentication@ietf.org" <draft-ietf-bfd-optimizing-authentication@ietf.org>
To: Reshad Rehman <rrahman@cisco.com>
References: <86B2BDA3-B8BC-4ABF-A073-30844E7254FD@cisco.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/qDgSliYqK3axU4zIRZ6bd8pzt7I>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 Jul 2020 04:13:43 -0000

Hi Reshad,

Happy Canada day!

Thanks first of all for the shepherd writeup. Please see my comments/questions inline.

@Ashesh, please comment on the change to the table.

> On Jun 14, 2020, at 11:50 AM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
> 
> Authors, WG,
>  
> The writeup is available at https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/>
>  
> For convenience I’ve copied the comments on the document below.
>  
> Regards,
> Reshad.
>  
> General:
> Updates RFC5880 missing from title page

Hmm. How does one add the “Updates” tag?

> Replace BFD frames by BFD packets or BFD control packets. Don’t use frames since RFC5880 uses packets.

Done.

> Use of term Null-authentication TLV. RFC5880 uses authentication section, doesn’t mention auth TLV.

Ok. Have changed all references of “NULL Auth TLV” to “NULL Auth Type”.

>  
> Abstract:
> Mention that this document updates RFC5880.

Done.

>  
> Requirements Language
> Please put this is a separate (sub)section later, e.g. after introduction.

Done.

>  
> Introduction
> First paragraph: s/is computationally intensive process/is a computationally intensive process/

Done.

> Split first sentence into 2, e.g.
>    Authenticating every BFD [RFC5880] packet with a Simple Password, or
>    with a MD5 Message-Digest Algorithm [RFC1321], or Secure Hash
>    Algorithm (SHA-1) algorithms is a computationally intensive process.
>    This makes it difficult, if not impossible, to authenticate every packet,
>    particularly at faster rates.

Done.

>  
> 2nd paragraph: “… only BFD frames that signal a state change in BFD be authenticated.” State change is not 100% correct since P/F/D bit changes aren’t state changes (as mentioned in more detail below in section 2 comments). What about this instead: “State change, a demand mode change (to D bit) or a poll sequence change (P or F bit change) in a BFD packet are categorized as a significant BFD change. This document proposes that all BFD control packets which signal a significant BFD change MUST be authenticated if the session’s bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and received without the A bit set.” If you do use “significant BFD change”, add it to terminology section.

Done.

> s/non-state change frame/BFD control packets without state or D/F/P bit change/, e.g.
> “To detect a Man In the Middle (MITM) attack, it is also proposed that BFD control packets without a significant change be authenticated occasionally.  The interval of these control packets…”

Done.

>  
> Section 2
> POLL and DEMAND are NOT strictly states. POLL refers to “Poll sequence” as specified in section 6.5 of RFC5880. DEMAND refers to “Demand mode” as specified in section 6.6 of RFC5880. In the table, the POLL entry refers to polling sequence enabled and in any BFD state. Likewise, the DEMAND entry refers to Demand mode. This means that a session in UP state, in demand mode and polling sequence enabled will match 3 entries in that table. It’s a bit confusing. Here’s what I suggest instead:
> Take POLL out of the table. Add a paragraph mentioning that if P or F bit changes value, the packet MUST be authenticated
> Take DEMAND out of the table. Add a paragraph mentioning that if D bit changes value, the packet MUST be authenticated

Have made the change as follows. I am hoping Ashesh can comment on it.

The significant changes for which authentication is being suggested
   include:

          Read   : On state change from <column> to <row>
          Auth   : Authenticate frame
          NULL   : No Authentication. Use NULL AUTH Type.
          n/a    : Invalid state transition.
          Select : Most packets NULL AUTH. Selective (periodic)
                   packets authenticated.
         +--------+-----------+---------+---------+
         |            | DOWN   | INIT   | UP     |
         +--------+--------+--------+--------+
         | DOWN   |  NULL  |  Auth  |  Auth  |
         +--------+--------+--------+--------+
         | INIT   |  Auth  |  NULL  |  n/a   |
         +--------+--------+--------+--------+
         | UP     |  Auth  |  Auth  | Select |
         +--------+--------+--------+--------+

                       Optimized Authentication Map

   If P or F bit changes value, the packet MUST be authenticated.  If
   the D bit changes value, the packet MUST be authenticated.


>  
> Another comment on the table. The text says it should be read as state change from column to row. Column INIT to row UP is n/a whereas column UP to row INIT is Auth. INIT to UP is a valid transition, UP to INIT is not (has to go through DOWN first). So I think those entries should be reversed in the table.

Done.

>  
> Last paragraph: CC frames is not defined in BFD, use “control packets” instead?

Done.

>  
> Section 3
> Sequence number mentions “as defined in [RFC5880]”. Suggest mentioning bfd.XmitAuthSeq

Done.

>  
> Security Considerations.
> I believe this needs to be beefed up:
> Use of sequence number for non-authenticated frames. Secure sequence numbers even better.
> Mention (again) that non-authenticated BFD packets which have a significant change (state, D/F/P) are dropped. So if someone injects a non-authenticated packet with Down state to take down the session, that won’t work.

The Security Considerations section now reads as follows:

  The approach described in this document enhances the ability to
   authentication a BFD session by taking away the onerous requirement
   that every frame be authenticated.  By authenticating packets that
   affect the state of the session, the security of the BFD session is
   maintained.  In this mode, packets that are a significant change but
   are not authenticated, are dropped by the system.  Therefore, a
   malicious user that tries to inject a non-authenticated packet, e.g.
   with a Down state to take a session down will fail.  That combined
   with the proposal of using sequence number defined in Secure BFD
   Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers] further
   enhances the security of BFD sessions.



>  
> Section 6.2
> RFC5880 should be a normative reference.

Done.

Mahesh Jethanandani
mjethanandani@gmail.com