secdir review of draft-ietf-tsvwg-ecn-mpls-02.txt

[Tom Yu <[e-mail]>]

This is a review of draft-ietf-tsvwg-ecn-mpls-02.txt.

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.

I am not very familiar with MPLS or Diffserv, but I did read some of
the cited MPLS and ECN references in order to understand this
document.

I mostly agree with the claim in the Security Considerations that this
proposal introduces no additional vulnerabilities.  However, although
this document indicates that using a RFC3540 ECN nonce to detect
misbehaving receivers continues to work under this proposal, a RFC3540
nonce can also be used to detect disruption of the end-to-end
continuity of ECN signaling.  This proposal can compromise the
detection of disruptions of end-to-end ECN signaling continuity which
occur within a given MPLS domain.  I lack the context to determine
whether this is a serious problem.

The procedure described in RFC3540 relies on the existence of two
distinct ECT indications to convey a single bit's worth of nonce data
to the receiving transport endpoint.  This proposal functionally uses
only a single bit to indicate a CM state.  If a malicious or
malfunctioning element within the MPLS domain clears a CM state set by
some LSR, the egress LSR will not set the CE state in the
unencapsulated IP packet.  Consequently, the receiving transport
endpoint acts as if the packet did not have a CE state marked at all,
and the sending transport endpoint receives no indication that a
problem exists with end-to-end ECN signaling.

In effect, the MPLS domain behaves as a single black box router from
the perspective of RFC3540, masking any ECN signaling anomalies
internal to the MPLS domain.  This may be an acceptable consequence of
this proposal, but it would be useful to know whether this consequence
has been considered.

---Tom

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf