Early Review of draft-ietf-tsvwg-ecn-tunnel-
review-ietf-tsvwg-ecn-tunnel-secdir-early-hanna-2010-05-11-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 comments.

This document describes revised, consistent semantics for setting
the ECN (Explicit Congestion Notification) field in the IP header
on entry to and exit from any IP in IP tunnel. The document updates
RFC 3168 (the main ECN RFC) and RFC 4301 (IPsec) to say that all
IP in IP tunnels should follow the new rules for setting the ECN bits.
The new rules are similar to the IPsec rules, with the exception of
special handling for several previously unused combinations of the
ECN bits. These unused combinations provide support for PCN
(Pre-Congestion Notification).

The primary security concern here is that the ECN bits can serve as
a covert channel allowing parties inside and outside the secure area
to communicate even though they are not supposed to be able to do so.
Malicious parties inside the secure area can set the ECN bits on
packets to carefully selected values, exposing 2 bits of information
per packet to parties outside the secure area. This covert channel
can also operate in the opposite direction (insecure to secure).

During the development of RFC 4301, the IPsec Working Group evidently
determined that the risks of leaving this small covert channel open are
exceeded by the benefits of allowing ECN information to be properly
processed end-to-end. Therefore, they elected to permit the ECN bits
to be copied from inner to outer IP headers at tunnel ingress
(encapsulation) and described how the ECN bits in the outer IP header
can be merged into the inner IP header at tunnel egress (decapsulation).

The document under review proposes to standardize ECN handling for
all IP in IP tunnels with a system that is very similar to the
current IPsec behavior. The only difference is that the merging
of ECN bits at tunnel egress better accommodates PCN.

Because the IPsec Working Group has previously decided that the
risks of this small covert channel are exceeded by the benefits
of properly functioning ECN and the only change here is to
increase the benefits of ECN be supporting PCN, I conclude that
the document under review is not problematic from a security
perspective. In fact, it can be considered beneficial since it
will help avoid dropped packets due to undetected congestion.
This improves availability, which is a security characteristic.