Re: Roman Danyliw's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

Greg Mirsky <> Wed, 18 December 2019 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35E5412085E; Wed, 18 Dec 2019 08:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aKsTu_FcfOOI; Wed, 18 Dec 2019 08:28:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F98A120170; Wed, 18 Dec 2019 08:28:53 -0800 (PST)
Received: by with SMTP id k8so2836574ljh.5; Wed, 18 Dec 2019 08:28:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yboy+07TjaN7HXahmNKecG4aPNUYpbFicrNa7UeQTcE=; b=GAKESkNzsjBnybum68rFBukRM88cX5oxfblkagsubcuoHCPf3ZqTBysnRNbpOWjwR7 a5hL0bqMMSVbOxbyFbVmjkJB+X4gGsnrzcD55gya3jx7/hIh0mFKgmvxU3HnBSBMlB3P ogpNzsowIxUZaCm1x5vhCyR0nRx9l1kAwbe30m6gA11FIqA0qnPUIZq9DIWBRVjOh3He IEIQr7ulJQQjDy5YUoLvEVZgX5g9jyE6bf2wTNEiEMWg8AtmThX2u5NkIO4+At3RmWP2 WckBq9Wej4e/8Wo51xtk49BtqSwXpCtNsie6fUwi39JThGU+kFHwHGSetH0U1ceE/Q3S RNiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yboy+07TjaN7HXahmNKecG4aPNUYpbFicrNa7UeQTcE=; b=goNlZThA6ohl7ZrInhUO8LK5fmhDGg6NigvS78KrcXqo8ehKq0uJsRyd1Q59rUrLRK qYuN+9IEB8Jba5lxl94+YyDCG3oQDRKSFv39DO0MMOaJN5uyXhlJ6+zCjPLQsS2lJKa8 smhixI80rE7Emr5wgN4FyOTNeoofdLjhJlc1FH+DIzBUXeuCay6aEfrThiXgy1I0sPOl VMQtXinpOMTz/ZYfA2kqCpASHUkfkVx350An106DQRd7jz0QmWCAunV/l+Q9QrODdyj3 tWTX/8T+J5ZEz9DonGyjiFtOF80IULGFXZ8GVYUDpveobkwsXobcSg/Tgv6xkoRkgDCJ ezYw==
X-Gm-Message-State: APjAAAVJW7xhS043uE/u+Hd4sd3LcoLqbsij2oSYnJdVpl+DxU1TFoqz cQtiyc5KItxSyeBL7BV5mJ2bnHGwJS6G0jq4lkM=
X-Google-Smtp-Source: APXvYqw8QPrYZAoLuyBSXoOfPiOhnafYg9hRNpOrX3n/6iwQQu3lG3pUMvwz8h22cQ7skuuLfvUXydDcY2UtXhMyZI4=
X-Received: by 2002:a2e:88c5:: with SMTP id a5mr2481760ljk.201.1576686531149; Wed, 18 Dec 2019 08:28:51 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Wed, 18 Dec 2019 08:28:40 -0800
Message-ID: <>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)
To: Roman Danyliw <>
Cc: The IESG <>,, Jeffrey Haas <>,, rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="0000000000009c85020599fcf07a"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Dec 2019 16:28:56 -0000

Hi Roman,
thank you for your review, detailed questions, and helpful suggestions. All
editorial changes applied to the working version of the document. Please
find my answers in-line below tagged GIM>>.

Best regards,

On Mon, Dec 16, 2019 at 6:01 PM Roman Danyliw via Datatracker <> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-bfd-vxlan-09: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I support Ben Kaduk’s DISCUSS position.
> * Section 9. Per “The document requires setting the inner IP TTL to 1,
> which
> could be used as a DDoS attack vector”, could you please clarify what
> part(s)
> of the notional architecture would be impacted (e.g., physical, virtual;
> and
> how)?
GIM>> The scenario we've considered is when a VXLAN tunnel is broken. A
packet that is not using an address from the loopback range (or from
IPv4-mapped addresses for that range for IPv6) may be routed and TTL or Hop
count will be zeroed on the next node. The impact likely to be noticed on
the control plane. Would you agree?

> * Section 9. Per:
>    Thus the implementation MUST have
>    throttling in place to control the rate of BFD Control packets sent
>    to the control plane.  On the other hand, over-aggressive throttling
>    of BFD Control packets may become the cause of the inability to form
>    and maintain BFD session at scale.  Hence, throttling of BFD Control
>    packets SHOULD be adjusted to permit BFD to work according to its
>    procedures.
> I’m having difficulty parsing the guidance above – it points out the need
> to
> throttle and the ramifications of doing so.  Per the last sentence, could
> you
> please clarify how the throttling should be calibrated.
GIM>> I think that it is very much implementation-specific. For example, an
implementation may throttle control packets per BFD session or use a more
aggregate approach. On the other hand, intervals at which BFD Control
packets being transmitted and received play some role in selecting the
throttling limits.

> * Section 9.  Per “this specification does not raise any additional
> security
> issues beyond those of the specifications referred to in the list of
> normative
> references”, I recommend being clearer which references you mean (i.e., I’m
> assuming you don’t mean RFC2119, RFC8174, etc.)
GIM>> Thank you for pointing to this ambiguity. The updated text:
   Other than inner IP TTL set to 1 and limit the number of BFD sessions
   between the same pair of VTEPs, this specification does not raise any
   additional security issues beyond those discussed in [RFC5880],
   [RFC5881], and [RFC7348].
Would it address your concern?

> * Editorial Nits:
> - Abstract. s/forming up/used to form/
> - Section 9. s/such address/such an address/