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

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Oct 2017 07:35:07 -0700

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.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 10 Oct 2017 00:00:30 +0000

Hi, Stephen,

Thanks for the review, please see inline.

> On Oct 6, 2017, at 10:35 AM, Stephen Farrell <[email-masked]> wrote:
> 

Thanks!

> 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:
https://tools.ietf.org/html/rfc8029#section-3.4.1.2

That in turn gets updated by this with OSPF and ISIS:
https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-11#section-6

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.
https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-11#section-5.1

So...

> That's defined as:

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

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

Hopefully, verified.

Thanks again, Stephen for the security review.

— Carlos.