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

"Susan Hares" <shares@ndzh.com> Fri, 19 August 2016 16:13 UTC

Return-Path: <shares@ndzh.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 79B9012D125; Fri, 19 Aug 2016 09:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no
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 CJkdgw1Ztihl; Fri, 19 Aug 2016 09:13:29 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 401D712D18A; Fri, 19 Aug 2016 09:13:28 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170;
From: "Susan Hares" <shares@ndzh.com>
To: "'Kathleen Moriarty'" <kathleen.moriarty.ietf@gmail.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> <CAKKJt-dikQt9+5GQFHrWSv-cvM1Eu8_c660OnHsJ32KXLDX38g@mail.gmail.com> <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> <CAHbuEH7mWBow2Az=xxtRFuW7gDK30wo-A5ZKsZsdRTWPE+8ztg@mail.gmail.com> <004 d01d1fa32$e30d 3f20$a927bd60$@ndzh.com> <CAHbuEH7VF84wyknqasn3cKHWheSqvTSoVg8+raruJzjJdQLTXg@mail.gmail.com>
In-Reply-To: <CAHbuEH7VF84wyknqasn3cKHWheSqvTSoVg8+raruJzjJdQLTXg@mail.gmail.com>
Date: Fri, 19 Aug 2016 12:12:10 -0400
Message-ID: <007801d1fa34$71141540$533c3fc0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXAKYJpUpAop25V4CQIq52gGudSksAidU2ZKedSuuMA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/asIBASF6LEdHQqmd_hOt0uRxxno>
X-Mailman-Approved-At: Fri, 19 Aug 2016 09:15:16 -0700
Cc: i2rs@ietf.org, 'Alissa Cooper' <alissa@cooperw.in>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, i2rs-chairs@ietf.org, 'Andy Bierman' <andy@yumaworks.com>, 'IESG' <iesg@ietf.org>, 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>, '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 16:13:31 -0000

Kathleen:

Responding to: 

KM: What I had asked earlier was if you could set a flag to say the data wasn't confidential and didn't require integrity protection.  The operator could decide how they want to treat the data in that circumstance and you might only put this flag in the data model in places that you think the trigger is needed.

Sue: 
There is no mechanism to do this in Yang right now.  There is a proposal on how such a flag to be placed in the data model in places that need this trigger in draft-hares-i2rs-protocol-strawman.

Sue 


-----Original Message-----
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Friday, August 19, 2016 12:10 PM
To: Susan Hares
Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; i2rs-chairs@ietf.org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey Haas; Joel Halpern; draft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi Sue,

On Fri, Aug 19, 2016 at 12:01 PM, Susan Hares <shares@ndzh.com> wrote:
> Kathleen:
>
> First of all, I agree software knobs can always be set to multiple settings in vendor settings.  These settings may expand beyond standard models, and operators may set these knobs as they wish.
>
> As a security person, do you really want a standardized knob that says "run this model over non-secure transport"?

KM: What I had asked earlier was if you could set a flag to say the data wasn't confidential and didn't require integrity protection.  The operator could decide how they want to treat the data in that circumstance and you might only put this flag in the data model in places that you think the trigger is needed.

Kathleen

 I do not want non-secure transport used for configuration and most operational status.  Corrupted data in the MGT plane can corrupt data
traffic in the network.   The bar for non-secure transport has to be
very high with lots of warnings.  Therefore an operator having a switch to change attribute (such as a configuration attribute) from a secure transport to a non-secure transport - should be discouraged.
>
> Yang 1.1 has three places to indicate:
>  1) Attribute - on the yang syntax on an attribute (leaf node or leaf 
> list),  or portion of a schema,
>  2) model - meta-data on yang modules contained in library.
>  3) mount points - where multiple modules are mounted.
>
> [Andy or Juergen may provide more details on meta-data on yang module 
> libraries.  Lada or Lou can provide more details on mount points. ]
>
> Early in our discussion, NETCONF/NETMOD asked us to be specific in our requirements.   In the final discussion, we put Yang syntax so the level could be attribute to provide the level of check you indicated.   It could go to any of these places if it works,.
>
> Does this discussion help?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen 
> Moriarty
> Sent: Friday, August 19, 2016 11:27 AM
> To: Susan Hares
> Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; 
> i2rs-chairs@ietf.org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey 
> Haas; Joel Halpern; 
> draft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on 
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and 
> COMMENT)
>
> On Fri, Aug 19, 2016 at 11:02 AM, Susan Hares <shares@ndzh.com> wrote:
>> Spencer:
>>
>>
>>
>> Thank you for asking.  The time it would take is the time to move the 
>> configuration knob to “always transport-secure” for this model.
>
> Why does the knob in the data model have to be set only one way?
> Couldn't an attribute be used that you could change the setting for that attribute rather than update the entire YANG module or is that not possible in YANG?  Couldn't this be a setting?
>
> Thanks,
> Kathleen
>
>>
>>
>>
>> Sue
>>
>>
>>
>> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
>> Sent: Friday, August 19, 2016 10:13 AM
>> To: Susan Hares
>> Cc: Andy Bierman; 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)
>>
>>
>>
>> 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
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>



-- 

Best regards,
Kathleen