[conex] draft-ietf-conex-destopt

Bob Briscoe <bob.briscoe@bt.com> Mon, 06 October 2014 20:52 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ABA2C1A8A03 for <conex@ietfa.amsl.com>; Mon, 6 Oct 2014 13:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.087
X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MyKJIDd2KdF2 for <conex@ietfa.amsl.com>; Mon, 6 Oct 2014 13:52:19 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627E11A89C6 for <conex@ietf.org>; Mon, 6 Oct 2014 13:52:19 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net ( by EVMHR65-UKRD.bt.com ( with Microsoft SMTP Server (TLS) id; Mon, 6 Oct 2014 21:52:17 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net ( by EVMHR72-UKRD.domain1.systemhost.net ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 6 Oct 2014 21:52:16 +0100
Received: from bagheera.jungle.bt.co.uk ( by EPHR02-UKIP.domain1.systemhost.net ( with Microsoft SMTP Server id; Mon, 6 Oct 2014 21:52:16 +0100
Received: from BTP075694.jungle.bt.co.uk ([]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s96KqFQ3003785; Mon, 6 Oct 2014 21:52:15 +0100
Message-ID: <201410062052.s96KqFQ3003785@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 6 Oct 2014 21:52:13 +0100
To: Mirja =?iso-8859-1?Q?K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Suresh Krishnan <suresh.krishnan@ericsson.com>
From: Bob Briscoe <bob.briscoe@bt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/Anh2jZwRM3nT_Codkb744Ym4LuE
Cc: "ralli@tid.es" <ralli@tid.es>, ConEx IETF list <conex@ietf.org>
Subject: [conex] draft-ietf-conex-destopt
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2014 20:52:21 -0000

Mirja, Suresh,

I promised (offlist) that I would post the following suggested text 
to the list for the Security Considerations of conex-destopt. This 
would replace the current single sentence that simply says "This 
document does not bring up any new security issues." which doesn't 
sound very reassuring.



[abstract-mech] describes the overall audit framework for assuring 
that ConEx markings truly reflect actual path congestion. This 
section focuses purely on the security of the encoding chosen for 
ConEx markings.

The chg bit in the CDO option type field is set to zero, meaning that 
the CDO option is immutable. If IPsec AH is used, a zero chg bit 
causes AH to cover the CDO option so that its end-to-end integrity 
can be verified, as explained in Section 4.

It has been specified that the Reserved field in the CDO must be 
ignored and forwarded unchanged even if it does not contain all 
zeroes. The Reserved field is also required to sit outside the 
encrypting security payload (ESP), at least in transport mode (see 
Section 7). This seems to allow the sender to use the Reserved field 
as a 28-bit-per-packet covert channel to send information to an 
on-path node outside the control of IPsec. However, a covert channel 
is only a concern if it can circumvent IPsec in tunnel mode and, in 
the tunnel mode case, ESP would close the covert channel as outlined 
in Section 7.

Bob Briscoe,                                                  BT