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

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 01 October 2015 03:52 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 B43AF1AD084; Wed, 30 Sep 2015 20:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 clzdUpcOjiy7; Wed, 30 Sep 2015 20:52:29 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9A81AD080; Wed, 30 Sep 2015 20:52:28 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-21-560c4e70200e
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.6C.32596.07E4C065; Wed, 30 Sep 2015 23:04:48 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 23:52:27 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
Thread-Index: AQHQ+90XGTaaybntuU+HziqlvMWDDQ==
Date: Thu, 1 Oct 2015 03:52:26 +0000
Message-ID: <E87B771635882B4BA20096B589152EF63A97724C@eusaamb107.ericsson.se>
References: <20151001000655.11590.32411.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPt26BH0+Ywdud4hbnHl5msjh07Sej xcNH6RbvT31ht+he/YvdYsaficwW0/deY3dg91jbfZXNY8mSn0weM469ZA9gjuKySUnNySxL LdK3S+DKWPitg7HgkFhFz5OdLA2MJ4S6GDk5JARMJPbcm8oGYYtJXLi3Hsjm4hASOMoo8fJP GyuEs5xRYu+TfnaQKjagjg07PzOB2CICnhIP+06xgBQxC8xnkjj67zIzSEJYIEaiaUErI0RR rMS1YwehGvQk5k3cDWazCKhI7N2/lRXE5hXwlfh94gELiC0k4Chx4fJOsDgj0EnfT60Bq2cW EJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2tsSyha+ZIXYJSpyc +YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNjECY+mYBJvuDsY9Ly0PMQpwMCrx 8Coo84QJsSaWFVfmHmKU5mBREufdv+R+qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGZMkl 8bPv1oSZr1plfuOvf2KqkGIb85kXT1fqX58XPeHFdCOGP+rJgnwWf5kMMo5fYl86pe6r4i+m uuWVj2MV16Zcvxc1jV9j5uGI7PWHND8pVvYXSujvaZK/esQ9OOdlkt6J8tATgnY5n0U6GQ3q rKu6OTRkFh41+nngvEWIcUwZj+XC6/uVWIozEg21mIuKEwH7cu14hgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/NEamjtEhDw8RwekJ_uwI9ECp6QU>
Cc: "draft-ietf-conex-destopt.ad@ietf.org" <draft-ietf-conex-destopt.ad@ietf.org>, "conex-chairs@ietf.org" <conex-chairs@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, 01 Oct 2015 03:52:30 -0000

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/
>
>
>
> ----------------------------------------------------------------------
> 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. 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] https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html

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