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

"Carlos Pignataro (cpignata)" <> Tue, 10 October 2017 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74D0A1320C9; Mon, 9 Oct 2017 17:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZwzZf9haQRq; Mon, 9 Oct 2017 17:01:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5183E120720; Mon, 9 Oct 2017 17:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3938; q=dns/txt; s=iport; t=1507593696; x=1508803296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bOMMiPHyHXylwm8a6kZnUGRicHjn2sGVHtX7r5RqMZA=; b=RH9NPAR3HkGmapy4KBs4ZzBfNtRy7wDHoR35eZEL9eV1pX0rfETkDe1z YPfKBwln/feXsbCKZ9sgnf8Mck9rYFLyoVajFIXgxh2y0PivpgIw15HDv nisUXHPqvJvfRtbI1njpk4wiAUboEROFCgG8AUGW5bbXFrn6OKOL6RhnJ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.42,502,1500940800"; d="scan'208";a="308667405"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 00:00:31 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9A00Uut002350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Oct 2017 00:00:31 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 9 Oct 2017 20:00:30 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 9 Oct 2017 20:00:30 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Stephen Farrell <>
CC: "" <>, mpls <>, "" <>, "" <>
Thread-Topic: Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11
Thread-Index: AQHTPrBSI1p/j3GTGEeyOcbEmYYd56LcezoA
Date: Tue, 10 Oct 2017 00:00:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Oct 2017 00:01:38 -0000

Hi, Stephen,

Thanks for the review, please see inline.

> On Oct 6, 2017, at 10:35 AM, Stephen Farrell <> wrote:
> 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:-).

The idea of the “Protocol” field exists from RFC 8029, both implicitly and explicitly.

First, as part of the Downstream information as per:

That in turn gets updated by this with OSPF and ISIS:

Second, within a request, it is implied in the type of Target FEC Stack (TFS) — see the Table of Contents of RFC 8029, Sections 3.2.X (LDP, RSVP, BGP, etc.)

This spec adds TFSes that allow different protocols, so it is explicitly now as either OSPF or ISIS. The alternative was to separate these into two TFSes and have the protocol as implicit, but since the are mutually exclusive and distribute the same TFS info, it makes more sense to use a single TFS with a protocol field.


> 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,

This is used only to validate that the FEC was advertised by that protocol, same as previous TFSes by LDP or BGP or RSVP.

> 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),

Nope, it does not, as per detailed explanation above.

> 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.

That is correct. But we do not only say “no biggie, we know what it means”, I am detailing the reasons why this is so.

> If so,
> that's probably fine, but it might be good to verify that.

Hopefully, verified.

Thanks again, Stephen for the security review.

— Carlos.

> Cheers,
> S.