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

Spencer Dawkins at IETF <> Fri, 19 August 2016 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A08DC12D98F; Fri, 19 Aug 2016 06:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L2sp6NMnxVfs; Fri, 19 Aug 2016 06:08:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30DEA12D9B9; Fri, 19 Aug 2016 06:08:11 -0700 (PDT)
Received: by with SMTP id b59so2467703ybi.0; Fri, 19 Aug 2016 06:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m1WiyN7eu4hboa0YJJW8QrKkOhWfikZvdOBL5XNXylg=; b=JVcfsqxNdDbN2wWhjlfwZWuTvQNSSwEbptvYp+L8iGfnSCVcnBOXYwfdS2YxTHbe9N EXDw2tRK/iG2vuRHvvaYSYQTnyVB1PN+OWKFqrAdEsK6JSjF5Up31s+liTCTkDAu7qt2 tgRcYg5I0RYd+s0Q4C0sQ3rInM0leaCFUj2pZuDvkIXNp5M6UEMiWlBz5I1SgHOOC5ed umQjG1xLGaiME8ksA0eRbUi6DAddRQnUKem2bOKxDofFR3Ylqw1vNqxKc3LFMhDUxGFc FqamwXrb3eLgOaS6ohtGEYphihbQcrzaBuscjP62rnta3PoOMu/LfydOVrEk5ZSF7g3X nb/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m1WiyN7eu4hboa0YJJW8QrKkOhWfikZvdOBL5XNXylg=; b=dPfbDdNBc9yJH3UOIQaWS8+I3iZnw3J5Op5LERU8BTT53/e+0wGoJ3dkmDk4X5gdKm D9MHlHnFeG5z4/FvRsh8IT9iFAjXU1JEgrM+9Va4e/xGBRVfxC6jDfg83me48Uygf2hK 5POPXBvQ5eU17d2L75+H4pg/hLU6RzKX8/l2r7AlYwIz6xDRbE3voQCxrKKmREugEJVj nv1y4qQ1Xxf6goI74VWkod6lVZegenhT9NZG7RCYdjiRJDncSnq3vbr9tYK1RrttpEOy S3KthkZqsNqwC9OjYzcRvCae720PIME7UFHZA49peZhQexKpqu9qnxxqF/9CJ5IRmHDf GADQ==
X-Gm-Message-State: AEkoousDKy8qiWZegDXcGLdxZmR2TFnapU2uFjt+F/c8C6dHvYY+UD/Fd1RykFnnx7LRSZaghgPBTDM3BFz4cQ==
X-Received: by with SMTP id f35mr5900916ybi.98.1471612090459; Fri, 19 Aug 2016 06:08:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 Aug 2016 06:08:09 -0700 (PDT)
In-Reply-To: <>
References: <> <013b01d1f8ee$31fa09b0$95ee1d10$> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$> <> <> <003801d1f97f$3d16eb10$b744c130$> <> <00dc01d1f988$f2cec280$d86c4780$> <>
From: Spencer Dawkins at IETF <>
Date: Fri, 19 Aug 2016 08:08:09 -0500
Message-ID: <>
To: Andy Bierman <>
Content-Type: multipart/alternative; boundary=94eb2c138950e62b54053a6c6365
Archived-At: <>
X-Mailman-Approved-At: Fri, 19 Aug 2016 06:29:47 -0700
Cc: "" <>, Alissa Cooper <>, Juergen Schoenwaelder <>,, Kathleen Moriarty <>, IESG <>, Jeffrey Haas <>, Joel Halpern <>, Susan Hares <>,
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Aug 2016 13:08:32 -0000

Dear All,

On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman <> wrote:

> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <> 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.