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

"Susan Hares" <> Fri, 19 August 2016 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED05512DA30; Fri, 19 Aug 2016 06:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jAsEvopzmNLa; Fri, 19 Aug 2016 06:31:57 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F11012DA01; Fri, 19 Aug 2016 06:31:24 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Spencer Dawkins at IETF'" <>, "'Andy Bierman'" <>
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$> <> <> <02b201d1fa1c$620e07d0$262a1770$>
In-Reply-To: <02b201d1fa1c$620e07d0$262a1770$>
Date: Fri, 19 Aug 2016 09:30:05 -0400
Message-ID: <02ca01d1fa1d$ccd71ba0$668552e0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CB_01D1F9FC.45C70240"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXJ7OxVXA
Content-Language: en-us
Archived-At: <>
X-Mailman-Approved-At: Fri, 19 Aug 2016 06:52:08 -0700
Cc:, 'Alissa Cooper' <>, 'Juergen Schoenwaelder' <>,, 'Kathleen Moriarty' <>, 'IESG' <>, 'Jeffrey Haas' <>, 'Joel Halpern' <>,
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:31:59 -0000



Let me clarify one thing.   The deployment of new Yang modules can be sent with any software update cycle.  A software update cycle takes hours in some environments and months in others.  The question is what is the longest a yang module can stay the network.  Andy suggests 20+ years (probably based on SNMP deployments).  


I have posted version -09.txt.   




From: Susan Hares [] 
Sent: Friday, August 19, 2016 9:20 AM
To: 'Spencer Dawkins at IETF'; 'Andy Bierman'
Cc:; 'Alissa Cooper'; 'Juergen Schoenwaelder';; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern';
Subject: RE: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)




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?  


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’ve release a version-09.txt that tries to make this very clear.   Please comment on that text to help make this clear. 





From: Spencer Dawkins at IETF [] 
Sent: Friday, August 19, 2016 9:08 AM
To: Andy Bierman
Cc: Susan Hares;; Alissa Cooper; Juergen Schoenwaelder;; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern;
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 <> wrote:



On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <> wrote:



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.