[IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compat RFC4301 update

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Tue, 30 March 2010 16:20 UTC

Message-Id: <201003301620.o2UGKMVA006770@bagheera.jungle.bt.co.uk>
Date: Mon, 22 Mar 2010 17:13:49 +0000
To: ipsec@ietf.org
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: tsvwg chair <tsvwg-chairs@tools.ietf.org>
Subject: [IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compat RFC4301 update
Precedence: list

IPsecME folks,

I would like to draw your attention to 
<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-tunnel/> from 
the transport area w-g.

You may recall I gave early warning of this work to the Security Area 
open meeting back in July'09. A formal SecDir review has just been 
requested, but voluntary reviews from other people who live & breath 
IPsec would also be greatly appreciated. We want to get this right.

Please include me in the distr if you post any issues (or 
non-issues), as I'm not permantently subscribed to <ipsec@ietf.org>. 
Ideally cc <tsvwg@ieft.org>.

You will notice it updates 4301 decap. I want to emphasise that the 
update only affects a combination of inner & outer that is currently 
unused (CU) - existing 4301 behaviour remains completely unchanged, 
and it adds no modes or options.

Abstract is below.

Cheers


Bob

========================================================================
Transport Area Working Group                                  B. Briscoe
Internet-Draft                                                        BT
Updates: 3168, 4301                                       March 03, 2010
(if approved)
Intended status: Standards Track
Expires: September 4, 2010


              Tunnelling of Explicit Congestion Notification
                      draft-ietf-tsvwg-ecn-tunnel-08

Abstract

    This document redefines how the explicit congestion notification
    (ECN) field of the IP header should be constructed on entry to and
    exit from any IP in IP tunnel.  On encapsulation it updates RFC3168
    to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
    ECN processing.  On decapsulation it updates both RFC3168 and RFC4301
    to add new behaviours for previously unused combinations of inner and
    outer header.  The new rules ensure the ECN field is correctly
    propagated across a tunnel whether it is used to signal one or two
    severity levels of congestion, whereas before only one severity level
    was supported.  Tunnel endpoints can be updated in any order without
    affecting pre-existing uses of the ECN field, providing backward
    compatibility.  Nonetheless, operators wanting to support two
    severity levels (e.g. for pre-congestion notification--PCN) can
    require compliance with this new specification.  A thorough analysis
    of the reasoning for these changes and the implications is included.
    In the unlikely event that the new rules do not meet a specific need,
    RFC4774 gives guidance on designing alternate ECN semantics and this
    document extends that to include tunnelling issues.



________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

[IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compa… Bob Briscoe