Re: [secdir] [Idr] Secdir early review of draft-ietf-idr-te-pm-bgp-13

"Susan Hares" <shares@ndzh.com> Fri, 19 October 2018 23:54 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886C1310FC; Fri, 19 Oct 2018 16:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 2FltK_QVj2w7; Fri, 19 Oct 2018 16:54:12 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 178461310B4; Fri, 19 Oct 2018 16:54:11 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.26.143;
From: Susan Hares <shares@ndzh.com>
To: 'Robert Raszuk' <robert@raszuk.net>
Cc: "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>, kaduk@mit.edu, idr@ietf.org, draft-ietf-idr-te-pm-bgp.all@ietf.org, ietf@ietf.org, 'Yoav Nir' <ynir.ietf@gmail.com>, secdir@ietf.org
References: <153972468642.9298.14442375581871750001@ietfa.amsl.com> <ec43e712e8024930831a206f8e843cbb@XCH-ALN-001.cisco.com> <7655493D-9EF0-42FF-B2D3-B9CE4E78178D@gmail.com> <feec42a72bd64f31afbcb3b340dad52b@XCH-ALN-001.cisco.com> <1FFA9449-D03C-4EB6-9D08-BA4A1AA93FE3@gmail.com> <92af26fef2da470d853f292c84f026a0@XCH-ALN-001.cisco.com> <20181019002642.GX19309@kduck.kaduk.org> <CAOj+MMH1=SBV=ikiNE6UHEe1mzf5xKLPOZXnnqPEvyFHTC=83A@mail.gmail.com> <00a601d467af$3c4b90f0$b4e2b2d0$@ndzh.com> <b718ffb671c446adb1666ad9f73f4f82@XCH-ALN-001.cisco.com> <028b01d467ce$402b2400$c0816c00$@ndzh.com> <f20b00331cbf42f49dcc5ab61c8d2d8f@XCH-ALN-001.cisco.com> <03e101d467f3$2bff9130$83feb390$@ndzh.com> <CAOj+MMH79aD2jzeVEWzv=WQS0y6N4VZyoeRmncPna1BtKmCeaA@mail.gmail.com>
In-Reply-To: <CAOj+MMH79aD2jzeVEWzv=WQS0y6N4VZyoeRmncPna1BtKmCeaA@mail.gmail.com>
Date: Fri, 19 Oct 2018 19:54:06 -0400
Message-ID: <04c301d46807$05d98bf0$118ca3d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04C4_01D467E5.7EC8D650"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKgXenR4TO/OdN54mRvtkcFsKB91wGNvGOlAbtG730CGuBt5QG8teXZAq/npckCVX567AF47qlpAfFlXbIB67+5BAE930AoAZRhPWMClJo7/QFrm+9foszUiUA=
Content-Language: en-us
X-Antivirus: AVG (VPS 181019-4, 10/19/2018), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/B1qPNs_Y0fejBlvGh8d8AeC_4NY>
Subject: Re: [secdir] [Idr] Secdir early review of draft-ietf-idr-te-pm-bgp-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2018 23:54:20 -0000

Robert: 

 

I disagree with many of your comment below.  However,  a discussion of these points is no longer appropriate on this thread. Les has indicated my suggested resolution of a revision to RFC7752 is not an acceptable alternative.   He wishes to focus on directly resolving these issues with the secdir.  This thread is closed to any further discussions on a revision of RFC7752.  

 

If you wish to discuss these offline, you can send me email.   If you wish to discuss these on a different thread, please start that specific thread.   

 

Sue

 

PS – The point of my questions were to explore if recasting the web of RFC7752 BGP peers as a trusted domain with the restrictions in RFC8402 would resolve security concerns related to RFC7752.  

 

From: Robert Raszuk [mailto:robert@raszuk.net] 
Sent: Friday, October 19, 2018 6:28 PM
To: shares@ndzh.com
Cc: Les Ginsberg (ginsberg); kaduk@mit.edu; idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; Yoav Nir; secdir@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Hello Sue,

 

However, I would like your feedback on whether you believe RFC7752 has security that is equivalent to, less than, or greater than a trusted domain? 

 

The spring routing architecture (RFC8402) indicates that be default SR operates within a trusted domain. 

 

“Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important.  Such practices are discussed in [RFC4381 <https://tools.ietf.org/html/rfc4381> ] and are applicable to both SR-MPLS and SRv6.”

 

 

Reading your comments I am also similarly to Les's feelings quite not sure what the point here is. 

 

SR Architecture while completely irrelevant to this thread talks about trusted domain in the context of data plane. Bringing in L3VPNs out of the sudden only because some SR document referred to it's security analysis is also quite a bizarre maneuver. 

 

With control plane and especially with BGP the notion of trusted vs untrusted domain is not something anyone can just pick or state on what his or her believe is. 

 

The short answer is that BGP operates on a per AFI/SAFI basis and level of trust is directly related to the actual configuration applied including level of policy inserted when using such apparatus to distribute various forms of information. 

 

Same SAFI can be configured by one operator quite strictly limiting it to one AS and someone else will like to share his information with entire world publishing it to a looking glass. Are we here to restrict this ? What means of control is there to enforce such restrictions other then perhaps stating simple recommendation in an advisory fashion that one should be a bit careful when publishing content of his LSDB or TED beyond devices he trusts ? **

 

** Note that even if TE infrastructure addresses or other information are accidentally leaked - there should be no great immediate harm - since well managed network prevents on ingress to the domain any flows which would aim at internal infrastructure address space. 

 

Thx,
R.