Re: [secdir] Secdir review of draft-ietf-mpls-rfc4379bis-07

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

Hello Vincent,


Many thanks for your review! Please find some responses inline.

On Oct 21, 2016, at 1:13 AM, Vincent Roca <[e-mail]<mailto:[e-mail]>> wrote:

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

IMHO, the document is Ready with issues.

I have two main comments:

1- This document has an interesting security considerations section. However it
lacks some key information. First of all, there is no attacker model. Is the
threat coming from corrupted equipment? Do we assume those attackers have full
control over the equipment and flows? Are attackers on path or off path?
Clarifying these points (it's not an exhaustive list) would help structuring the
discussion on a case by case basis.


The security considerations section covers the approaches to attacking LSRs using LSP Ping/Traceroute. This is an exhaustive list which includes active and passive attacks. Is there some specific attack you see that is not covered?


2- Something else to clarify: I have the feeling (after quickly searching integrity/
authentication/HMAC/... keywords in the doc) that is no message integrity
nor sender authentication mechanism in the echo request/response detailed here.

That is correct, no message integrity nor sender authentication in LSP Ping.

If the attacker model also includes a full control of LSR, nothing can be done to
prevent some attacks. Please clarify.


Sorry but if an attacker has full control of an LSR, she or he is probably too busy on said LSR to send LSP Pings :-)


And a few additional ones:

3- First sentence says:
   "Overall, the security needs for LSP ping are similar to those of ICMP ping."
Such debugging tools as ping and traceroute (not speaking of MPLS version here)
have an efficiency that heavily relies on (sometimes arbitrary) decisions made
by the system administrators whose security policies lead to total or partial
blackholes.
Hence my questions: is the situation similar with MPLS or can we expect more
homogeneous and favorable security policies (e.g., because there's a limited
number of administrative domains, or because we are not relying on an ICMP
mechanism any more, or because the present document is more directive on
what a system administrator should authorize/block/limit)?

Yes. We can expect a more homogeneous and favorable set of security policies, because of all those reasons.

This could change a lot the security aspects and the potential impacts on the
debugging tools.


4- Later it is said:
     "To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
     implementations regulate the LSP ping traffic going to the control
     plane.  A rate limiter SHOULD be applied to the well-known UDP port
     defined below."
- Do you mean port 3503? It is mentionned but not defined below in this section.
  Wording should be adjusted.

It actually is defined below. The Security Considerations is Section 5, and the port definition is in Section 6.

I added a more precise pointer:

   To avoid potential Denial-of-Service attacks, it is RECOMMENDED that
   implementations regulate the LSP ping traffic going to the control
   plane.  A rate limiter SHOULD be applied to the well-known UDP port
   defined in Section 6.1.

Thanks for the comment.


- It is not clear to me by reading this sentence if it concerns the sender
  (who sends traffic to the control plane) or forwarding nodes, which I guess
  are the target. In other words, "going to the control plane" is somewhat
  ambiguous.

If you look at the document locking on "sent to the control plane” and variations of it, the meaning will be clear.



5- Then:
     "To protect against unauthorized sources using MPLS echo request
     messages to obtain network information, it is RECOMMENDED that
     implementations provide a means of checking the source addresses of
     MPLS echo request messages against an access list before accepting
     the message."
Are ACL efficient in this context? If an attacker can forge the source address,
it's not. Unless some cryptographic mechanism is used, there's little hope to
provide a secure ping service. This is a follow up of comment 1.


This document does not goal itself in defining "secure ping”. It specifies “LSP Ping”, as a bis document.

However, if you have specific textual suggestions for improvement, those may also help clarify.


- Typo:
     "...an implementation MAY also validate the TimeStamp
     Sent by requiring an exact match on this field."
Sent => sent.

No. It’s the “TimeStamp Sent” field (see page 12).

Thanks again,

— Carlos.


Cheers,

  Vincent