Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 19 August 2016 14:13 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9276E12DA73; Fri, 19 Aug 2016 07:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oOEsmq3T1R3v; Fri, 19 Aug 2016 07:13:28 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DB712DA9C; Fri, 19 Aug 2016 07:13:20 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id j12so13398179ywb.2; Fri, 19 Aug 2016 07:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0JQRKWOOXdMN0kYs5q0pfF2ku89mHv+sCeOIXk9Z/Ho=; b=MW0kRmSm16t0KFn21DDL9o4rxRtIPDmBdTVjDxaYWYcqOBTvlbnKUjOABduLlSa1wr Jo6h6SXImRXUqBjKND3AZ1LBBFT0+cw+TEN1t0HHLBOWqOmjowJ8ZiyDH6df4Cffnyz1 ZM4J+7+eLo95XaNE1O6J/HBJGjSTb6VXjwCGn0cGaxnpFeHinYdeZDPXHRfPg983Gpoq Otv8DY/ZwLCnJcaVDNqeirgf6r0ve1mB9UK7Dl8QhC3oFzaTqmGgzCSJIUGk5tN9BkC2 xuXpst1lGFEm2ncph9RSn3kLTlpsB73vnCcJncdmKfbfahlkPLFql+ezI06oyFkrmz6z +w5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0JQRKWOOXdMN0kYs5q0pfF2ku89mHv+sCeOIXk9Z/Ho=; b=iaouGDHBU5EwCAyCyiGMbrDU3+BqP192uBD1Togm+17ucmGdY8ry6/Uaq9V9dg5J+s E/MSJubDdSWZIKzsj/XLXGX51vvgnHWzMzB+8I48YuowLdxmqxw5bARPnqgnpDuIiVei xzzLlTzuxbGBil/fdX5wrl7Z0ctfeu7jce8U6UbEa9+6eFuyM9YocrhQTpHk0drnXzEw Ak4qXE8LVDt8VIftlGb31v6kAtBs1CrUibXZ0n0PXG4XyORyGPzGtJTGMZ1raEDm1B4G C/zU/89Y7PRvGuR1ZRTzGVxtMTxmFlz1UYGWrKwyMJUvzYxXj/0OOo99I+Z8489sGhjN v9NA==
X-Gm-Message-State: AEkoouu5tw6gLlZVv50XPC3+pMr/Kf0yx8/NBvXtfy5EUKceBoBwUWmuXwSJKsY7Yunx+JVVMgX5Q9mUUH/54Q==
X-Received: by 10.129.82.130 with SMTP id g124mr6591162ywb.208.1471615999859; Fri, 19 Aug 2016 07:13:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.210.195 with HTTP; Fri, 19 Aug 2016 07:13:18 -0700 (PDT)
In-Reply-To: <02b201d1fa1c$620e07d0$262a1770$@ndzh.com>
References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <CABCOCHS-72KK0VgUARynb_19YLA5oM1g1odSLpezuBrq=+dmqg@mail.gmail.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <CABCOCHTSjeipwFsNvYZssDayu9axg=g=6mwmyxxfCvCyWfw0Fw@mail.gmail.com> <CAKKJt-d_P2W-D2jJpWBmANsza9bJRa8swumdeXpTTDsj6mbKBw@mail.gmail.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 19 Aug 2016 09:13:18 -0500
Message-ID: <CAKKJt-dikQt9+5GQFHrWSv-cvM1Eu8_c660OnHsJ32KXLDX38g@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a114dc320eae445053a6d4c24
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/kYY1FoQJ0Hpj5GGtYhwvnGXS9sc>
X-Mailman-Approved-At: Fri, 19 Aug 2016 08:01:35 -0700
Cc: i2rs@ietf.org, Alissa Cooper <alissa@cooperw.in>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, i2rs-chairs@ietf.org, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, IESG <iesg@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, Joel Halpern <joel.halpern@ericsson.com>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 14:13:31 -0000

Hi, Susan,

On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares <shares@ndzh.com> wrote:

> Spencer:
>
>
>
> You as asking if:
>
>
>
> 1)      Can Yang Models be revised?  - there is a revision tag on the
> Yang model.
>
> 2)      How long it takes to deploy revised models in the Internet, and
> old-models to be timed out?  This is an operational question on yang models
> that no one has experience to determine.   Andy suggest that the deployment
> time is 20 years (the Age of the Commercial internet – 1996 -2016) rather
> than the age of the Internet (1987-2016).
>
>
>
> However, the real question you should have asked is: Can operators deploy
> models which are marked as “non-secure transport” with a  secure transport?
>

I understood that part. My question was how long it would likely take them
to switch to a secure transport if they had deployed a model with an
insecure transport and figured out that was problematic.

Thanks for the explanation. It was helpful.

Spencer


> The answer is yes.  In fact, several operators in I2RS stated that all
> I2RS protocol communication needed to be secure.    Therefore, if the
> people found out that a model was problematic to be insecure – operators
> and vendors would simply turn the deployment knob switch that says – deploy
> this always with a secure transport rather than optionally allow an
> insecure transport.
>
>
>
> Now, the real problem is if the IESG has been cycling on this concept –
> the text needs to change.   I’m going to go ahead and release a
> version-09.txt that tries to make this very clear.   Please comment on that
> text to help make this clear.
>
>
>
> Sue
>
>
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
> *Sent:* Friday, August 19, 2016 9:08 AM
> *To:* Andy Bierman
> *Cc:* Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder;
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel
> Halpern; draft-ietf-i2rs-protocol-security-requirements@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Dear All,
>
>
>
> On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
>
>
> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrote:
>
> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>    SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>    secure transport and optionally MAY be able to transfer data over a
>    non-secure transport.
>
>
>
> I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>
>
>
>
>
> As I understand it, this requirement has another requirement associated
> with it
>
> that says the data has to be identified as OK-for-nonsecure-transport.
>
>
>
> An extension in the data model says that all instances of the object in
>
> all possible deployments cannot be considered sensistive and therefore
>
> needs disclosure protection.
>
>
>
> It may seem like even a simple octet counter is safe to send in the clear,
>
> but not if that opens up correlation attacks.  (e.g., I can send data to
> some
>
> host.  I can see that index 455992 is incrementing the in-octets counters
>
> in a way that strongly correlates to my test traffic.  Therefore I can
> learn
>
> that arbitrary index 455992 is really John Doe or really suite #14, etc.
>
>
>
> Since Kathleen asked what other ADs were thinking ...
>
>
>
> I'm current on this thread, as of the time I'm sending my note, but
> replying to Andy's note because it's poking where I am poking.
>
>
>
> So, if (say) an octet counter is considered safe to send in the clear, and
> a Yang model that reflects that is approved and widely deployed, and then
> someone realizes that it's not safe to send in the clear, is that a big
> deal to fix, and get the updated Yang model widely deployed?
>
>
>
> My opinion on this point has a lot to do with how hard it is to recover if
> a Yang model gets this wrong ...
>
>
>
> My apologies for not understanding enough about Yang and I2RS to be able
> to answer my own question, of course.
>
>
>
> Thanks,
>
>
>
> Spencer
>