[mpls] Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 06 October 2017 14:35 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 4ACCC1342E9; Fri, 6 Oct 2017 07:35:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: secdir@ietf.org
Cc: mpls@ietf.org, draft-ietf-mpls-spring-lsp-ping.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150730050726.13161.17866745423154681018@ietfa.amsl.com>
Date: Fri, 06 Oct 2017 07:35:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OLnoJ7eMOQyEG5DYrClZrCOwdeg>
Subject: [mpls] Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 06 Oct 2017 14:35:07 -0000

Reviewer: Stephen Farrell
Review result: Ready


Hiya,

The document describes yet another variant of ping and traceroute for 
MPLS, which is fine. The security considerations text is probably right
in saying there's no big delta here vs. RFC 8029.

I do have one query:

The "protocol" field in the requests here seems like it's maybe a new
thing, that wasn't in 8029 (or at least wasn't clearly there from my
fairly uninformed read:-). That's defined as:

      Set to 1, if the Responder MUST perform FEC validation using OSPF
      as IGP protocol.  Set to 2, if the Responder MUST perform Egress
      FEC validation using ISIS as IGP protocol.

I don't know what's required for those validation steps, nor if there's 
any chance that doing such validation could form a new DoS vector,
or if it could (interestingly) affect the interpretation of the information 
in the responses (say if validation can affect response timing in some
weird way), so this is just to check if there's anything more to be said
about that. I assume the authors' answer will be that implementers
of this will know what validation means here, that it's no big deal as
a DoS vector and that the timing effects are not a problem. If so,
that's probably fine, but it might be good to verify that.

Cheers,
S.