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

[Vincent Roca <[e-mail]>]

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.


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.
If the attacker model also includes a full control of LSR, nothing can be done to
prevent some attacks. Please clarify.


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


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.


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

Cheers,

  Vincent