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

Ashesh Mishra <mishra.ashesh@gmail.com> Sat, 04 July 2020 19:18 UTC

Return-Path: <mishra.ashesh@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 2D6B73A0EC9; Sat, 4 Jul 2020 12:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lw3ky56-AMWT; Sat, 4 Jul 2020 12:18:00 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 74D913A0EC7; Sat, 4 Jul 2020 12:17:59 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id g139so20334440lfd.10; Sat, 04 Jul 2020 12:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ogP6DN0bIcNyyZySXbAx4yh+sSTTMtMbfglj0p/3DyA=; b=DGJDt0X1puRBdCojhv3LsquCGV9LuCLjXAF+sHdJRTJCkJ+SualkwXjn8ndet85w1i euBJ3I4QkFM/8vInw6x+MDi4EJ165tZ0ft+R3BJsY+VJe/Vm2z1gnS8UT3Akd1StItKm 1i3NKxxW0ba50asI8iATt5FXz/9EbIdb2MUVY0Z83mYqQVUBvJ++i7B/2R1IegDx9760 mR6o1ad0poP6gVkaw/wR9HchTrbPzf+oNBPgwe1UOfe+T5Us4zZuepK1e34k4oyhRpU2 3Q5goLbdV8zqUV6LqkIZ4g7TIbbgXDp+EfuXRYuttGTq/4yv5cpTNePVAc3Mojd0Gkzc pcXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ogP6DN0bIcNyyZySXbAx4yh+sSTTMtMbfglj0p/3DyA=; b=fUP6oHAa/jlfLTmtlwfcCOKKCbxEZjzHqzfKW1lTYQdgIgxzgk/68kjEG6AADKZUOh EKhP7vCRxjunCETjd2X7svJaCaosbVyad67qMB+O3Alo/da+tF8p1SKFFa1VPAJB7xBc L8XVfsPOZOriIxjVBdSopXfwH16BnW8sgXcn6snzqM6W5lmaOShtgMpZk3XrVFhYyuDF y2oY9QoP0MwrpKX8jRQLgcLb29gXwxErIfDEFwIMOqasrbZKDP8K+28EU5jJv4cvq8G4 klcCtvZrITlV+mmQbAuDikOiL2bXbMU2nD42lbWIuUTEBT/nf++jiHK+O9XXEJ1YCH1F d0Sw==
X-Gm-Message-State: AOAM533pRwVBORdy2VhgHLWMLJgAKRrFp5HnlLSqVxqAOPGjNRFNFLQ6 CJe4txoc+LcnIk/M3sBKQMocIokD1brT8ru0znE=
X-Google-Smtp-Source: ABdhPJxLnaX1cbxAXdthhFF3KmkQnRX07P5T4PZ3IEgJjq0DJg1o8+Qt1PlrXaM/83Ky5KhY92GWT8qknPL1014XI+k=
X-Received: by 2002:ac2:5691:: with SMTP id 17mr25575922lfr.209.1593890277374; Sat, 04 Jul 2020 12:17:57 -0700 (PDT)
MIME-Version: 1.0
References: <86B2BDA3-B8BC-4ABF-A073-30844E7254FD@cisco.com> <8C54F0A2-0D11-4C50-B94F-19E6381365AE@gmail.com> <D205BB56-DA58-4C39-B278-BC318CF3C1ED@cisco.com>
In-Reply-To: <D205BB56-DA58-4C39-B278-BC318CF3C1ED@cisco.com>
From: Ashesh Mishra <mishra.ashesh@gmail.com>
Date: Sat, 4 Jul 2020 12:17:46 -0700
Message-ID: <CAHDNODLPfxMd-y_iZNaW-ae-e0Bup+cdmZ3hrEJtcnTFwaHuUw@mail.gmail.com>
Subject: Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-optimizing-authentication@ietf.org" <draft-ietf-bfd-optimizing-authentication@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cb3e1705a9a27f46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ayxX2vKuviBBmjFgYjV_SWJvI5c>
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: Sat, 04 Jul 2020 19:18:02 -0000

Hi Mahesh, On the Section-2 state transitions - the confusion seems to be
around the context of the "state". The section uses it to detect changes at
the receiver - if the frame that is received is different from the one that
was received previously, then should it (or should it not) be
authenticated. In that sense, the receipt of P, F and D represent changes
to the ongoing BFD session and should be authenticated. I agree with Reshad
that poll and demand are not state changes in the BFD state-machine - but
they change the state of the receiver logic (poll, for instance, can change
the interval which can cause instability). Hope that clarifies the
verbiage. Perhaps we can use a different term for it but I can't think of
one :)

--
Ash

On Thu, Jul 2, 2020 at 12:02 PM Reshad Rahman (rrahman) <rrahman@cisco.com>
wrote:

> Hi Mahesh,
>
>
>
> Thanks for the update.  I’ll re-review the updated document when it’s
> available.
>
>
>
> Inline <RR>
>
>
>
> *From: *Mahesh Jethanandani <mjethanandani@gmail.com>
> *Date: *Thursday, July 2, 2020 at 12:13 AM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>
> *Cc: *"rtg-bfd@ietf.org" <rtg-bfd@ietf.org>rg>, "
> draft-ietf-bfd-optimizing-authentication@ietf.org" <
> draft-ietf-bfd-optimizing-authentication@ietf.org>
> *Subject: *Re: Shepherd writeup for
> draft-ietf-bfd-optimizing-authentication
>
>
>
> 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/
>
>
>
> 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:
>
>    1. Take POLL out of the table. Add a paragraph mentioning that if P or
>    F bit changes value, the packet MUST be authenticated
>    2. 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.
>
> <RR> I’m good with this. I’m ok with doing this differently too, as long
> as the crux of my concern is still addressed.
>
>
>
>
>    1.
>
>
>
> 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:
>
>    1. Use of sequence number for non-authenticated frames. Secure
>    sequence numbers even better.
>    2. 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
>
> <RR> s/authentication a BFD/authenticate a BFD/
>
>    that every frame be authenticated.  By authenticating packets that
>
> <RR> s/every frame/every BFD control packet/
>
>    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.
>
>
>
>
>
> Regards,
>
> Reshad.
>
>
>
>
>
>
>    1.
>
>
>
> Section 6.2
>
> RFC5880 should be a normative reference.
>
>
>
> Done.
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>