[mpls] Roman Danyliw's No Objection on draft-ietf-mpls-ri-rsvp-frr-07: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 05 December 2019 13:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44378120020; Thu, 5 Dec 2019 05:40:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-ri-rsvp-frr@ietf.org, Nicolai Leymann <n.leymann@telekom.de>, mpls-chairs@ietf.org, n.leymann@telekom.de, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157555322727.16420.5929983933581091468.idtracker@ietfa.amsl.com>
Date: Thu, 05 Dec 2019 05:40:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/DQluEtXhVh06Urwqb7ncc3X3dUE>
Subject: [mpls] Roman Danyliw's No Objection on draft-ietf-mpls-ri-rsvp-frr-07: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2019 13:40:27 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-mpls-ri-rsvp-frr-07: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5. Recommend adding language about using more modern HMAC algorithms
than those suggested in RFC2747.  For example:

OLD:
The security considerations pertaining to the original RSVP protocol
[RFC2205], [RFC3209] and [RFC5920] remain relevant.

NEW:
The security considerations pertaining to the original RSVP protocol [RFC2205],
[RFC3209] and [RFC5920] remain relevant.  When using RSVP Cryptographic
Authentication [RFC2747], more robust algorithms such as HMAC-SHA256,
HMAC-SHA384, or HMAC-SHA-512 [RFC2104][SHS] SHOULD be used when computing the
keyed message digest where possible.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [SHS]      National Institute of Standards and Technology (NIST),
              FIPS Publication 186-3: Digital Signature Standard,
              October 2008.