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

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Thu, 08 October 2015 16:03 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC661A90FD; Thu, 8 Oct 2015 09:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8hxMTHaADVb; Thu, 8 Oct 2015 09:03:33 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E52C1A90DB; Thu, 8 Oct 2015 09:03:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 09A75D9321; Thu, 8 Oct 2015 18:03:21 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QPglbOop3BpI; Thu, 8 Oct 2015 18:03:20 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AD649D9320; Thu, 8 Oct 2015 18:03:20 +0200 (MEST)
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Bob Briscoe <ietf@bobbriscoe.net>, Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com> <E87B771635882B4BA20096B589152EF63A97724C@eusaamb107.ericsson.se> <560CEF4E.5080409@cs.tcd.ie> <560DAE68.60401@bobbriscoe.net> <560E45E2.2040809@cs.tcd.ie> <56130B0E.3000906@bobbriscoe.net> <56131DB8.1040109@cs.tcd.ie>
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Message-ID: <561693A4.2000609@tik.ee.ethz.ch>
Date: Thu, 08 Oct 2015 18:02:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56131DB8.1040109@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/OiTqJQFo29dxcN7Tncmn0ZJvJ4w>
Cc: "draft-ietf-conex-destopt.ad@ietf.org" <draft-ietf-conex-destopt.ad@ietf.org>, "conex-chairs@ietf.org" <conex-chairs@ietf.org>, The IESG <iesg@ietf.org>, "conex@ietf.org" <conex@ietf.org>, "draft-ietf-conex-destopt@ietf.org" <draft-ietf-conex-destopt@ietf.org>
Subject: Re: [conex] Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 08 Oct 2015 16:03:35 -0000

Hi,

I'm fine with the text below. But a quick question: Is there really a case 
where the attacker would alter the packet to make another network potentially 
drop the packet, instead of juts dropping it on its own?

Mirja


On 06.10.2015 03:02, Stephen Farrell wrote:
>
> Hiya,
>
> On 06/10/15 00:43, Bob Briscoe wrote:
>>
>> [Proposal #2]
>> A network-based attacker could alter ConEx information to fool an audit
>> function in a downstream network into discarding packets. However,
>> otherexisting attacks from one network on another such a TTL expiry
>> attacks are more damaging (because ConEx audit discards silently) and
>> less traceable (because TTL is meant to change, whereas CDO is not).
>
> That's better, yes.
>
> Probably no need to address it in this document but I guess our
> assumptions about other existing attacks might change as more and
> more network traffic is ciphertext at various layers. I'm also
> generally leery of arguments of the form "no need to do something
> here as there's a worse thing there" since those encourage us to
> do nothing anywhere, so I'd lose that kind of language if it can
> be done.
>
> S.
>