Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)

Stephen Farrell <> Thu, 01 October 2015 08:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD7CC1B2BD8; Thu, 1 Oct 2015 01:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8qvG86hfpaIe; Thu, 1 Oct 2015 01:31:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70CCB1B2BD7; Thu, 1 Oct 2015 01:31:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65B86BE35; Thu, 1 Oct 2015 09:31:16 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jn-_qQ7TLUsG; Thu, 1 Oct 2015 09:31:14 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 6392FBE33; Thu, 1 Oct 2015 09:31:13 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1443688274; bh=pBQfmxBfgt/i4Vj/zLBeOf87qERRzYenI+c+b3Gx8eY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WTIzxloyZ+qCEygwRCTjW8SzU91BMRcJnYiq/pRcCy0azP5V7qm292lPC/N7Gy9Nb FuNjL7f+H8Jdq63G+0OFmn3OUy+y0vVaApBtsCvkP2E7sn4N0VPzpbV7KbmLVIjDmy fRAh4X2HUezpbVZt6j8fL0eEvcozh6//YhMxifQI=
To: Suresh Krishnan <>, The IESG <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 1 Oct 2015 09:31:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Oct 2015 08:31:21 -0000


On 01/10/15 04:52, Suresh Krishnan wrote:
> Hi Stephen,
>    Thanks for your comments. Please find responses inline
> On 09/30/2015 08:06 PM, Stephen Farrell wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-conex-destopt-09: No Objection
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> - section 7: "If the transport network cannot be trusted, IPsec
>> Authentication should be used to ensure integrity of the ConEx
>> information." Hmm. Transport networks cannot be trusted so the
>> first condition is always met. That means you are saying IPsec
>> should be used. I don't see how the key management required is
>> going to happen and even if it did, would that affect conex
>> calculations? I'm ok with an experiment on that basis though,
>> but it'd be better if the real relationship between this and IPsec
>> were more fully fleshed out somewhere as part of the experiment.
> I am not sure if the form of key management chosen would affect the 
> conex calculations at all. 

My point is that the key management implied here is basically not
going to happen. That means IPsec will not be used and hence conex
calculations will need to take into account the potential for routers
to mess with the CDO.

And I think the text of this would be better if it recognised the
improbability of IPsec being used in the wild, or else spoke to how
one could arrange experiments so that use of IPsec is more likely.


> I did read RFC5406 and I am still not sure 
> what can be said here about key management. I would really appreciate 
> some pointers/suggestions/text here.
>> - The secdir review [1] touches on similar issues. I'm not sure if
>> that got a response, but it raises a good point that seems to me to
>> deserve a response.
>>     [1]
> I have added the following text in the Security Considerations section 
> of my local copy. Will submit this version after the telechat will check 
> with Robert. There is one item pending regarding audit in the Gen-ART 
> review and that may end up affecting this text.
>     This document does not define how audit mechanisms work in protocols
>     that use this option and how those protocols can protect themselves
>     from likely attacks.  This option MUST only be used alongside
>     protocols that define the audit mechanisms and the means for
>     protecting against likely attacks on such mechanisms.
> Thanks
> Suresh