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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Stephen,

Thanks for the review, please see inline.

> On Oct 6, 2017, at 10:35 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Reviewer: Stephen Farrell
> Review result: Ready
> 

Thanks!

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