[Cerowrt-devel] cerowrt 3.6.9-5

[Michael Richardson]

>>>>> "Dave" == Dave Taht <dave.taht at gmail.com> 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).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20121210/acee35e5/attachment.sig>