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"