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

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

Return-Path: <rbriscoe@jungle.bt.co.uk>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 19A873A6A02 for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 09:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.486
X-Spam-Level: **
X-Spam-Status: No, score=2.486 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_40=-0.185, DATE_IN_PAST_96_XX=1.69, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id a5riQo9JG-4X for <ipsec@core3.amsl.com>; Tue, 30 Mar 2010 09:20:15 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com []) by core3.amsl.com (Postfix) with ESMTP id 3DAF13A6A6E for <ipsec@ietf.org>; Tue, 30 Mar 2010 09:19:58 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 17:20:28 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 17:20:28 +0100
Received: From bagheera.jungle.bt.co.uk ([]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269966026605; Tue, 30 Mar 2010 17:20:26 +0100
Received: from MUT.jungle.bt.co.uk ([]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2UGKMVA006770; Tue, 30 Mar 2010 17:20:23 +0100
Message-Id: <201003301620.o2UGKMVA006770@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version
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
X-Scanned-By: MIMEDefang 2.56 on
X-OriginalArrivalTime: 30 Mar 2010 16:20:28.0035 (UTC) FILETIME=[E905C530:01CAD024]
Cc: tsvwg chair <tsvwg-chairs@tools.ietf.org>
Subject: [IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compat RFC4301 update
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2010 16:20:24 -0000

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>rg>. 
Ideally cc <tsvwg@ieft.org>rg>.

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.



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


    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