Re: [secdir] secdir review of draft-ietf-grow-bmp-15

Christopher Morrow <> Wed, 09 September 2015 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20F681B33A4; Wed, 9 Sep 2015 08:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xyIKxptvMm7e; Wed, 9 Sep 2015 08:46:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 482E21B339E; Wed, 9 Sep 2015 08:46:11 -0700 (PDT)
Received: by ykei199 with SMTP id i199so21452986yke.0; Wed, 09 Sep 2015 08:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H0MvrinFrq1gh7R8gL4scj4nqB5s2Jv6UEfTDS0L2XM=; b=L1C6qNSYAMIL0WFn1jxN2R/MZUZALJnI+cyERB/TssSv445OSI+pcuNXhjpkul315X 3HOIMtH3wZtGLATLecNHxuhFfT70U1NqzEHYqY4KmJLMZOfk33zpH0h4G/H/qxdO20Wh PvaQsV3fBKiSXACFryF8yXSEDRE9wjxcKgOAsJLaN3Pb7a556ngePUbrr/508+NL4Wdd x5+3ZA6vS0s5WIgb5nomSBdc+CwuNciFdL6ELH7QFmWh++8qHYvV4FtG+C1c5AAo34Tz sAumKGBLoezzIMtRF9Zth1g9KqKu7dw6N5VFViukMw+rsxE/P9qKHYC9ZcUx89KUuRNT XGyQ==
MIME-Version: 1.0
X-Received: by with SMTP id i206mr36188791ykc.51.1441813570143; Wed, 09 Sep 2015 08:46:10 -0700 (PDT)
Received: by with HTTP; Wed, 9 Sep 2015 08:46:10 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 9 Sep 2015 11:46:10 -0400
Message-ID: <>
From: Christopher Morrow <>
To: Hannes Tschofenig <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Approved-At: Wed, 09 Sep 2015 08:50:22 -0700
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-grow-bmp-15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2015 15:46:13 -0000

On Tue, Sep 8, 2015 at 3:09 PM, Hannes Tschofenig
<> wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
> I am not an expert in this field and cannot judge whether the designed protocol makes sense. The content did, however, look complete to me.
> The security consideration section talks about different security threats and focused on confidentiality protection quite a bit (but  dismisses it in the end). I would think that authentication and integrity are probably more important in this context. I suspect that a monitoring station will react on information it receives (somehow) and false information could potentially be a problem. How likely is it that an attacker injects false information that will then the processed by a monitoring station (which could be located anywhere)?
> Currently, it appears that no specific security solution is mandatory to implement. There are only examples listed, such as IPsec and TCP-AO. (For IPsec I guess you would also use IKEv2 as a key management?) Would it be useful to have one security mechanism mandatory to implement?

The only useful example protocol available on modern routers is ...
md5 tcp checksum... which if we add that to the draft we get kicked in
the teeth over :(

AO isn't even supported on modern unix systems, never mind 'not unix' systems.


there's another note about cisco not supporting this on
ios/ios-xe/ios-xr ... surprisingly to me Juniper might actually
support AO as of junos13 ?


oh! it seems it does, so neat.
(from a live device)
> show version
Hostname: rtr
Model: mx80-48t
Junos: 13.3R6.5

# set neighbor authentication-algorithm ?
Possible completions:
  aes-128-cmac-96      Cipher-based Message Authentication Code
(AES128) (96 bits)
  hmac-sha-1-96        Hash-based Message Authentication Code (SHA1) (96 bits)
  md5                  Message Digest 5

(this area is rife with 'the standards process is a bucket of fail')

AO would be nice, if we could actually get support in all the right
pieces... Making it a mandatory item though will keep BMP from being
deployable, I expect.

Here's the WG discussion on this actually:
(up and down a few messages is the gist of the discussion)

> The sentence "Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices." feels a bit out of context in the security consideration section. I would delete it from the security consideration section or, alternatively, what it implies in terms of security.
> The term 'transport' for a security protocol appears incorrect. For example, instead of writing "... users of this protocol should consider using some type of transport that provides mutual authentication, data integrity, and transport protection, ... " you could write "... users of this protocol should consider using a security protocol that provides mutual authentication, data integrity, and confidentiality protection, ... ".

This came up in a WG review I believe as well... in fact in the same
thread referenced above is the IPSEC bit of discussion.