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

Bob Briscoe <> Fri, 02 October 2015 08:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9CF6E1A1A4C; Fri, 2 Oct 2015 01:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0QVme0uaAHwc; Fri, 2 Oct 2015 01:21:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 869171A1A45; Fri, 2 Oct 2015 01:21:12 -0700 (PDT)
Received: from ([]:50964 helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <>) id 1ZhvaX-0005Up-HC; Fri, 02 Oct 2015 09:21:09 +0100
To: Suresh Krishnan <>, Stephen Farrell <>
References: <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 2 Oct 2015 09:21:09 +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=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, "" <>, "" <>
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: Fri, 02 Oct 2015 08:21:15 -0000


Sure - if Mirja is OK with that too.


On 02/10/15 05:08, Suresh Krishnan wrote:
> Hi Bob,
>     Thanks for your clarification. Since the security section seems to
> potentially have some dependence on the text needed for audit to address
> Robert's Gen-ART review, is it possible for you and Mirja to work
> offline and agree to some text before presenting it to the IESG?
> Thanks
> Suresh
> On 10/01/2015 06:06 PM, Bob Briscoe wrote:
>> Stephen, Suresh,
>> As the person that contributed some of the text for this IPsec section,
>> I can see what's happened during the evolution of the doc...
>> In section 4 it says
>> CDO MUST be placed as the first option in the destination option
>> header before the AH and/or ESP (if present).  IPsec Authentication
>> Header (AH) MAY be used to verify that the CDO has not been modified.
>> We started out writing Section 7 "Compatibility with use of IPsec" to
>> answering the question:
>> "What if IPsec is being used; how do we ensure ConEx is still visible?"
>> The answer was the above rule about placing CDO before AH and/or ESP.
>> In the process, we showed how endpoints that were already authenticating
>> their IP headers with IPsec would automatically get coverage for the
>> ConEx header. By some perverse document evolution process, this has become:
>> [Old]
>> If the transport network cannot be trusted, IPsec Authentication
>> should be used to ensure integrity of the ConEx information.
>> So I suggest the following change:
>> [Proposed]
>> If the endpoints are using the IPsec Authentication Header (AH) [RFC4302] to detect alteration of
>> IP headers along the path, AH will also ensure the e2e integrity of the CDO header.
>> Actually, both parts of the subsequent sentence are wrong as well:
>> [Old]
>> If an attacker would be able to remove the ConEx marks, this could cause an
>> audit device to penalize the respective connection, while the sender
>> cannot easily detect that ConEx information is missing.
>> a) Removing ConEx marks would make audit ignore those packets, not drop
>> them.
>> b) And It's not hard to design a protocol for the sender to detect
>> tampering with ConEx information.
>> So I suggest instead:
>> [Proposed]
>> A network-based attacker could alter ConEx information to fool an audit
>> function in a downstream network into discarding packets. An attack on
>> one network from another by changing an immutable field can be traced,
>> so it would be unlikely givennetwork operators care about their
>> reputation.Nonetheless, if ConEx information was being altered within a
>> network, IPsec AH or other more stealthy e2e integrity checks could be
>> useful tools to help pin-point the attack location.
>> No need to say this, but a similar attack is already possible: decrement
>> TTL in one network to cause another network to drop packets. This is
>> less easy to trace too, because it uses a mutable field.
>> BTW, I designed the precursor to ConEx (re-ECN) to make it possible for
>> networks to identify other rogue networks mounting such attacks, without
>> needing e2e authentication. But all the inter-network security only
>> works with ECN, not drop. When we decided to use ConEx to expose drop as
>> well as ECN, I couldn't make the drop-based aspects support these nice
>> security properties. That is admitted in conex-abstract-mech. But the
>> ECN side of ConEx still supports all the inter-domain security. None of
>> the inter-domain security techniques are written in the ConEx drafts,
>> but they're in my PhD thesis, and referenced from conex-abstract-mech
>> Security Considerations.
>> Bob
>> On 01/10/15 09:31, Stephen Farrell wrote:
>>> Hiya,
>>> 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:
>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>> - 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.
>>> Cheers,
>>> S.
>>>> 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
>>> _______________________________________________
>>> conex mailing list
>>> --
>>> ________________________________________________________________
>>> Bob Briscoe                     

Bob Briscoe