>>>>> "Dave" == Dave Taht writes: Dave> I worry about encapsulating protocols copying the inner TOS/Diffserv Dave> bits to the outer IP header. Using a shaper that is aware of these Dave> bits would end up delivering packets that depend on a sequential Dave> encrypted stream out of order. 1) RFC4301 is quite specific about this... it permits a window of up to 64 (even 128) out of order packets. It's not a problem. Dave> My head explodes when trying to understand AH and ipsec (strongswan), Dave> however, and I'd rather set up one and look at packets than try to Dave> understand the code. ENOTIME... and that leaves ipip etherip and Dave> encap, and l2tp left to look at. 2) Strongswan, unless it added in it's IKEv2 implementation, could negotiate how to set/copy ECN bits. However, that was never in openswan historically (from which strongswan forked) L2TP generally is no longer used without IPsec. The ECN bits are "fresh" on new packets.... the issue is propogating them into the inner packet on decap. I don't know if the Netkey kernel IPsec code is compliant to RFC3168 or not, but it's a decap concern, not an encap shaping concern. RFC4306: 2.24. Explicit Congestion Notification (ECN) When IPsec tunnels behave as originally specified in [RFC2401], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see [RFC3168]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 MUST support the ECN full- functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications. RFC4301: 5.1.2. Header Construction for Tunnel Mode ... o IPsec describes how to handle ECN or DS and provides the ability to control propagation of changes in these fields between unprotected and protected domains. In general, propagation from a protected to an unprotected domain is a covert channel and thus controls are provided to manage the bandwidth of this channel. Propagation of ECN values in the other direction are controlled so that only legitimate ECN changes (indicating occurrence of congestion between the tunnel endpoints) are propagated. By default, DS propagation from an unprotected domain to a protected domain is not permitted. However, if the sender and receiver do not share the same DS code space, and the receiver has no way of learning how to map between the two spaces, then it may be appropriate to deviate from the default. Specifically, an IPsec implementation MAY be configurable in terms of how it processes the outer DS field for tunnel mode for received packets. It may be configured to either discard the outer DS value (the default) OR to overwrite the inner DS field with the outer DS field. If offered, the discard vs. overwrite behavior MAY be configured on a per-SA basis. This configuration option allows a local administrator to decide whether the vulnerabilities created by copying these bits outweigh the benefits of copying. See [RFC2983] for further information on when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to IPsec processing (including tunnel decapsulation).