[secdir] Secdir review of draft-ietf-pals-mpls-tp-mac-wd-02

[Radia Perlman <[e-mail]>]

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.

This document proposes a new subtype to a Pseudo-Wire Operations,
Administration, and Maintenance (PW OAM) Message for the purpose of
withdrawing learned MAC addresses when those addresses cease being
accessible. Label Distribution Protocol (LDP) provides this functionality
for dynamically created pseudo-wires. This RFC defines a mechanism for
doing so in the case of statically provisioned pseudo-wires.

The security considerations section of this document says “The security
measures described in [RFC4447], [RFC5085], and [RFC6073] are adequate for
the proposed mechanism.” That may well be true, but the mechanisms in those
documents are based on address reachability only (rather than cryptographic
mechanisms) and therefore assume a closed network with security enforced by
filtering at access points. Forging messages of this protocol could cause
significant denial of service opportunities for an attacker.

Non-security issues:

On page 5, figure 1, TLV length is an 8 bit field defined as “the total
length of all TLVs in the message”. It does not specify the units, which I
assume come from some other spec. If this is a length in bytes, 255 bytes
seems like an exceptionally small limit for this length.

If I’m reading this correctly, this protocol seems to be a lot less
resilient to lost and reordered packets than it might be. In figure 1, the
use of an ‘R’ bit to reset the sequence numbers seems dangerous if messages
can be delivered out of order. Also, if all copies of a message sent with
the ‘R’ bit are lost, all subsequent messages will also be lost.

On page 6, section 4.1, paragraph 3 says that if additional MACs need to be
withdrawn before a previous withdraw message has been acknowledged,
retransmissions of the old message will cease and the new message will be
transmitted. It does not say whether the new message should combine the
MACs from the old message or not. If not, the probability of the MACs in
the old message being lost is increased. The spec should say one way or the
other.

Nits:

The spec should be reviewed to assure that the words "withdraw" and
"withdrawal" are used consistently. I couldn't discern what the pattern was
supposed to be. On page 2, "withdrawl" should be replaced with one or the
other.

P3: "loss of MAC withdraw signal" -> "loss of a MAC withdraw signal"
P3: "but do not assure" -> "but does not assure"
P4: "plackets" -> "packets"
P7: "acknowledgement is received" -> "acknowledgement is received."  (need
period end of sentence)
P7: "described in [RFC4385]" -> "described in [RFC4385]." (add period end
of sentence)
P7: "Security Consideration" -> "Security Considerations"