Last Call Review of draft-ietf-mpls-rfc4379bis-07
review-ietf-mpls-rfc4379bis-07-secdir-lc-roca-2016-10-27-00

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 t

wo 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

Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail