[secdir] secdir re-review of draft-ietf-mpls-residence-time-14

Benjamin Kaduk <kaduk@mit.edu> Wed, 01 March 2017 22:21 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FED129581; Wed, 1 Mar 2017 14:21:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 NOy0BqStke9P; Wed, 1 Mar 2017 14:21:41 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC227128AB0; Wed, 1 Mar 2017 14:21:40 -0800 (PST)
X-AuditID: 1209190c-da3ff7000000515e-67-58b74972d641
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A9.BB.20830.27947B85; Wed, 1 Mar 2017 17:21:39 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v21MLbu3020722; Wed, 1 Mar 2017 17:21:37 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v21MLXOa019003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Mar 2017 17:21:36 -0500
Date: Wed, 01 Mar 2017 16:21:33 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-residence-time.all@ietf.org
Message-ID: <20170301222133.GH30306@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUixG6nolvsuT3CYMdvTovv//axW8z4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MroeXKUvWC7QEXTtIwGxom8XYycHBICJhJt O+cydzFycQgJtDFJ7Dj0nwXC2cAocfjGcjYI5wqTxPx/71hBWlgEVCQm/7nGDGKzAdkN3ZeB bA4OEYEIiR0bykDCwgJ2EstPTGQCsXmBNpw9dI4RwhaUODnzCQuIzSygJXHj30smkFZmAWmJ 5f84QMKiAsoSDTMeME9g5J2FpGMWko5ZCB0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq 5WaW6KWmlG5iBIUWpyTPDsYzb7wOMQpwMCrx8GYwbI8QYk0sK67MPcQoycGkJMq7e9W2CCG+ pPyUyozE4oz4otKc1OJDjBIczEoivBOsgcp5UxIrq1KL8mFS0hwsSuK8EhqNEUIC6Yklqdmp qQWpRTBZGQ4OJQneZR5AjYJFqempFWmZOSUIaSYOTpDhPEDDV4PU8BYXJOYWZ6ZD5E8xKkqJ 8zKCJARAEhmleXC9oNiXyN5f84pRHOgVYd7lIFU8wLQB1/0KaDAT0OAXKltBBpckIqSkGhjN nk51cmd4ciUn1T04jC1APtfZfM5+1fdfLTfXekWbXfiXm7th468u48Rv2ZMii+ubZXkSN/n7 z4xsZ1oxT1qvc/OXmoo/Za2T49+cfhIw+8ZOecHFqR22V576nSmJ3rom7+bstWsP7zX8YmUw MU+0ZomY3q7vC+Icy51P/uPca1pfoGiZPleJpTgj0VCLuag4EQDNZ2wz2AIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/AFPXMmvqEFWJIWe09n1roBKxqEI>
Subject: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2017 22:21:43 -0000

I previously reviewed the -12
(https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html);
the -14 seems much improved.  On this re-read, I have a better sense
of how the various TLVs and sub-TLVs fit together to achieve the
goal of having the RTM-capable nodes identify each other and
collaborate to account for residence time when processing timing
packets.

I have no security concerns with the document, as the updated
security considerations address the concerns previously raised.

However, there are a couple of issues that should probably block
publication (but ought to be easy to resolve):

Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7
bits, 'Length' 8, 'I' 1, and 'Reserved' 15.  Presumably Type is
intended to be the full 8 bits, given the assigned values in the
registry.

On page 16, second paragraph:

   The ingress node MAY inspect the I bit flag received in each RTM_SET
   TLV contained in the LSP_ATTRIBUTES object of a received Resv
   message.  Presence of the RTM_SET TLV with I bit field set to 1
   indicates that some RTM nodes along the LSP could be included in the
   calculation of the residence time.  An ingress node MAY choose to
   resignal the LSP to include all RTM nodes or simply notify the user
   via a management interface.

Is that supposed to be "included" or "excluded"?  My reading of the
previous paragraph was that the I bit would be set when a node
failed to compute the next RTM-capable node along the path, and of
course, we expect normal operation to include the residence time for
all RTM-capable nodes, so signalling potential inclusion is odd.


I'll close off this review by noting that sections 4.3 through 4.6
seem to all talk about how to use other protocols to indicate that
RTM may be used and could perhaps be grouped into an intermediate
subsection, wondering whether the "Type" and "Length" fields in
Figure 2 are the same octets of the packet as in Figure 1, and
repeating my as-yet unfulfilled intention to send further minor
editorial patches to the authors.

-Ben