Last Call Review of draft-ietf-pals-mpls-tp-mac-wd-02
review-ietf-pals-mpls-tp-mac-wd-02-secdir-lc-perlman-2015-10-15-00

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"