Re: [secdir] secdir review of draft-ietf-rtgwg-lne-model-05

Lou Berger <> Thu, 15 February 2018 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA801126D05 for <>; Wed, 14 Feb 2018 17:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2vbCAy8J63t for <>; Wed, 14 Feb 2018 17:45:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F04F31270AC for <>; Wed, 14 Feb 2018 17:45:24 -0800 (PST)
Received: from CMOut01 (unknown []) by (Postfix) with ESMTP id A7117400FF for <>; Wed, 14 Feb 2018 18:45:24 -0700 (MST)
Received: from ([]) by CMOut01 with id AplM1x00P2SSUrH01plQEl; Wed, 14 Feb 2018 18:45:24 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=NU8yDOOJHQZyhqKhIhMA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fVNVvbR01nJs0GsVwnEYpO/SiEYgLQO4adGS0tN1+XA=; b=T2twDP8m4TwsE+ZD54ocxHCEBU S0jv0mYLXYtST3ewA47EMXjQ7NQd5PPE+7FA99coC1btbCQLKeJz0vixQ/ASquG6oNpCMUyCGmw7l W/V0OU+LdafjDvNLPgWt3bM1u;
Received: from ([]:43518 helo=[IPv6:::1]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <>) id 1em8bx-003Pmi-FS; Wed, 14 Feb 2018 18:45:21 -0700
To: Taylor Yu <>,,,
References: <ldva7wl8wet.fsf@ubuntu-1gb-nyc1-01.localdomain>
From: Lou Berger <>
Message-ID: <>
Date: Wed, 14 Feb 2018 20:45:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <ldva7wl8wet.fsf@ubuntu-1gb-nyc1-01.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1em8bx-003Pmi-FS
X-Source-Sender: ([IPv6:::1]) []:43518
X-Email-Count: 27
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-lne-model-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Feb 2018 01:45:29 -0000

Hi Taylor,

     Please see responses below.

On 2/6/2018 7:40 PM, Taylor Yu wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> The summary of the review is Ready With Issues.
> I agree somewhat with the Major Concerns in Russ Housley's Gen-ART
> review
> although I disagree that it makes the document Not Ready.
>> Major Concerns:
>> Section 4 listed three data nodes that are sensitive or vulnerable:
>>     -  /logical-network-elements/logical-network-element
>>     -  /logical-network-elements/logical-network-element/managed
>>     -  /if:interfaces/if:interface/bind-lne-name
>> All three of them deserve a bit more discussion, although the middle
>> one is covered in much more detail than the other two.  If a bad actor
>> gets "unauthorized access" is there something more specific about each
>> of these that can be said?  The characterization of "network
>> malfunctions, delivery of packets to inappropriate destinations, and
>> other problems" seems very broad.  Consequences that are specific to
>> these data nodes would be more helpful to the reader.
> My limited understanding is that there is a lot of variation in the
> security impact among specific equipment models and deployment
> scenarios.  Therefore, they would likely need to be analyzed on a
> case-by-case basis.  Perhaps there should be Security Considerations
> text to this effect, maybe with some broad guidance about how to do such
> an analysis?

I think this is still a little too vague for me to know what to add. On 
the other hand...
> For example, does changing the "bind-lne-name" of an interface have the
> effect of making it unavailable to the LNE it was previously associated
> with, while providing the new LNE with an unconfigured new interface?
> Or does it also carry some configuration or routing state from the
> former LNE with it to the new LNE?  The latter might have a greater
> security impact.

This is *very* helpful, we in fact have considered this case under the 
general text, but highlighting in here makes perfect senses. How about:
      Implementations should pay particular attention to when
       changes to this leaf are permitted as removal of an interface from
       an LNE can have major impact on the LNEs operation as it is
       similar to physically removing an interface from the
       device. Implementations can reject an reassignment using the
       previously described error message generation.

> This final paragraph in the Security Considerations of this document
> seems copied almost verbatim from that of RFC 8022:
>>     Unauthorized access to any of these lists can adversely affect the
>>     security of both the local device and the network.  This may lead to
>>     network malfunctions, delivery of packets to inappropriate
>>     destinations, and other problems.
> That seems to have been acceptable for RFC 8022, but perhaps we should
> do better here?  Or do we follow the precedent that this level of
> detail in the Security Considerations of YANG specifications is
> acceptable?

Note that 
doesn't include this text so if you'd like we can remove it to remain 
consistent with current guidelines.

Thank you for the comments!

> Best regards,
> -Taylor