Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

Jeffrey Haas <jhaas@pfrc.org> Wed, 02 December 2020 21:38 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F93A161F for <grow@ietfa.amsl.com>; Wed, 2 Dec 2020 13:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 375mX1vv5XQV for <grow@ietfa.amsl.com>; Wed, 2 Dec 2020 13:38:30 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EC4483A1664 for <grow@ietf.org>; Wed, 2 Dec 2020 13:37:57 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 31F301E355; Wed, 2 Dec 2020 16:54:43 -0500 (EST)
Date: Wed, 02 Dec 2020 16:54:43 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Tim Evens (tievens)" <tievens@cisco.com>
Cc: Job Snijders <job@ntt.net>, "grow@ietf.org" <grow@ietf.org>
Message-ID: <20201202215442.GD29769@pfrc.org>
References: <20201103061327.GU82986@bench.sobornost.net> <4EBBA87D-7522-4FE7-832B-5A4F13AE576E@pfrc.org> <4F5272B7-6A73-4F9D-8256-C6E2B6353408@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4F5272B7-6A73-4F9D-8256-C6E2B6353408@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/x8xtng4PJAx-kyZPwtFEsxAEZxM>
Subject: Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 21:38:41 -0000

Tim,

On Wed, Nov 04, 2020 at 06:01:14PM +0000, Tim Evens (tievens) wrote:
> I've updated this to UTF-8. From a receiver point of view, we handle utf-8 generically without any special need to deserialize it.  I suggest we do not attempt to define structure and/or constraints around the VRF names as that would severely impact system implementations that are out-of-scope of this draft. 
> 
> How about if we add:
> 
> "The structure, syntax, and constraints for a VRF name are router specific."

I see that you did the change to UTF-8.  My comment wasn't that we should
insist the VRF name has any specific semantics.  The issue is largely that
which is discussed here in RFC 8203:

https://tools.ietf.org/html/rfc8203#section-6

:   This document uses UTF-8 encoding for the Shutdown Communication.
:   There are a number of security issues with Unicode.  Implementers and
:   operators are advised to review Unicode Technical Report #36 [UTR36]
:   to learn about these issues.  UTF-8 "Shortest Form" encoding is
:   REQUIRED to guard against the technical issues outlined in [UTR36].
:
:   As BGP Shutdown Communications are likely to appear in syslog output,
:   there is a risk that carefully constructed Shutdown Communication
:   might be formatted by receiving systems in a way to make them appear
:   as additional syslog messages.  To limit the ability to mount such an
:   attack, the BGP Shutdown Communication is limited to 128 octets in
:   length.

You'll need similar boilerplate comments your security considerations.  In
the absence of such comments, you'll be facing a rather stiff bit of IESG
commentary. :-)

For shorter context for this list, the issue is roughly two things:
- You're sending along a byte string that has implicit lengths for each of
  the encoded characters.  You need to deal with issues when the implicit
  character length is not properly contained in the TLV you get on the wire.
  (This topic is in need of an IETF tutorial.)
- Some of the stuff in UTF-8 is "bad".  You'll want to filter that.

Since we have an RFC that cleared such review comments, including some
flavor of the 8203 security considerations will make your life happier.

-- Jeff