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

"Susan Hares" <shares@ndzh.com> Fri, 19 October 2018 23:22 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 15D36131096; Fri, 19 Oct 2018 16:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.936
X-Spam-Level: **
X-Spam-Status: No, score=2.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 4RyNmIbn7hIT; Fri, 19 Oct 2018 16:21:58 -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 913F9130ED9; Fri, 19 Oct 2018 16:21:57 -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: 'John E Drake' <jdrake@juniper.net>, "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>, 'Robert Raszuk' <robert@raszuk.net>, kaduk@mit.edu
Cc: idr@ietf.org, draft-ietf-idr-te-pm-bgp.all@ietf.org, ietf@ietf.org, 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> <44855683021a4ffbb8070364182d9d53@XCH-ALN-001.cisco.com> <043b01d467fb$813ba910$83b2fb30$@ndzh.com> <BN7PR05MB4354891AD79FD0F53777797DC7F90@BN7PR05MB4354.namprd05.prod.outlook.com>
In-Reply-To: <BN7PR05MB4354891AD79FD0F53777797DC7F90@BN7PR05MB4354.namprd05.prod.outlook.com>
Date: Fri, 19 Oct 2018 19:21:50 -0400
Message-ID: <047501d46802$84930d40$8db927c0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0476_01D467E0.FD887220"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKgXenR4TO/OdN54mRvtkcFsKB91wGNvGOlAbtG730CGuBt5QG8teXZAq/npckCVX567AF47qlpAfFlXbIB67+5BAE930AoAZRhPWMClJo7/QIHRbY5AaMT4hcBo/mJ2KKtuYDw
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/vfXl-8gR25oZeJ_lIY1bIALS_kE>
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:22:01 -0000

John: 

 

Per Les’s request we are trimming any discussion of my suggested solution to let him focus on resolving the issues with the sec-dir people.     

 

IMHO I do not think Les was close to resolving the issue main issue, but we both can watch and read as he continues to discuss this point with the secdir people.   As WG chair, I will continue to support resolution of secdir comments. 

 

Respectfully, Sue 

 

PS - Your personal comments regarding my email on SR or RFC7752 miss the point that RFC8402 resolves many issues by declaring the SR area a trusted domain. 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John E Drake
Sent: Friday, October 19, 2018 6:41 PM
To: Susan Hares; 'Les Ginsberg (ginsberg)'; 'Robert Raszuk'; kaduk@mit.edu
Cc: idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Hi,

 

Comments inline

 

Yours Irrespectively,

 

John

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 6:32 PM
To: 'Les Ginsberg (ginsberg)' <ginsberg@cisco.com>; 'Robert Raszuk' <robert@raszuk.net>; kaduk@mit.edu
Cc: ynir.ietf@gmail.com; idr@ietf.org; ietf@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; secdir@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Les:

 

I politely asked for viewpoint on RFC7752’s security since your draft depends on RFC7752.  You have impolitely and harshly refused to comment on these points.  

 

I am focused on finding a resolution to the security directorates comments on this draft on this thread.   One resolution was to suggest a general resolution by revising the RFC7752 draft.   I have spent time today providing background and reasons why this might be a good resolution.  I see from your comments that you are rejecting this potential resolution. 

 

[JD]  What part of “this draft has nothing to do with segment routing” do you not understand”? 

 

Propose a resolution to the secdir comments.    Please note as your shepherd and WG chair, stating  “security directorate does not understand BGP” is not a resolution. 

 

[JD]  From whom did that direct quote come?  I don’t recall seeing it on the email thread.  

 

IMHO as shepherd for your document Yoav has a valid point that on vagueness of RFC7752 and the addition of new information.   Please continue to work with Yoav, Benjamin and the secdir to resolve their concerns since my resolution has been rejected by you. 

 

[JD]  I just re-read the entire email thread on this draft and it appears to me that that the above is exactly what Les was doing and that he was quite close to a resolution before you injected RFC 7752bis and segment routing into the conversation. 

 

Sue Hares

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 6:01 PM
To: Susan Hares; 'Robert Raszuk'; kaduk@mit.edu
Cc: idr@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ynir.ietf@gmail.com
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Sue –

 

I will not reinforce your inappropriate insertion of the discussion of possible RFC 7752 deficiencies into a thread which is reviewing draft-ietf-idr-te-pm-bgp. This is wrong – please stop it.

 

You want to discuss issues with RFC 7752 – please start a separate thread – directed at the WG (of course) – and state your position as a WG member as to what you feel needs to be done. Then others can comment and the WG can decide whether they agree work needs to be done.

 

Also - and for the third time - draft-ietf-idr-te-pm-bgp is NOT SR related – please also stop inserting a discussion of SR/BGP-LS into the review of this draft.

 

(Apologies for the harsh tone – but it is becoming increasingly frustrating to watch this thread being misdirected.)

 

   Les

 

 

From: Susan Hares <shares@ndzh.com> 
Sent: Friday, October 19, 2018 2:32 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Robert Raszuk' <robert@raszuk.net>; kaduk@mit.edu
Cc: idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Les:

 

I will respond to this information point by point after I have responded to Ketan who sent me messages regarding his draft prior to yours.   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.   It says further: 

 

“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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4381&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=nSYW85l7_rYWox4dgWJmIPDGtX17whuzGQ0GFgNsWnU&e=> ] and are applicable to both SR-MPLS and SRv6.” 

 

If you believe that RFC7752 describes a trusted domain [per RFC4381], 

RFC7762 does not state that it is a trusted domain. 

 

If you believe the RFC7752 has stronger security 

than a trusted domain, can you let me know 

why you think it is stronger than a trusted domain.  

 

If you believe that RFC7752 describes security which 

is less than a trusted domain, please let me how it is less. 

 

The RFC7752 text is below for ease of the IDR and secdir readers. 

 

Thank you for providing this feedback, 

 

Sue

 

------------

 

RFC7752 security section (section 8.)  

 

8.  Security Considerations

 

   Procedures and protocol extensions defined in this document do not

   affect the BGP security model.  See the Security Considerations

   section of [RFC4271] for a discussion of BGP security.  Also refer to

   [RFC4272] and [RFC6952] for analysis of security issues for BGP

 

   In the context of the BGP peerings associated with this document, a

   BGP speaker MUST NOT accept updates from a consumer peer.  That is, a

   participating BGP speaker should be aware of the nature of its

   relationships for link-state relationships and should protect itself

   from peers sending updates that either represent erroneous

   information feedback loops or are false input.  Such protection can

   be achieved by manual configuration of consumer peers at the BGP

   speaker.

 

    An operator SHOULD employ a mechanism to protect a BGP speaker

   against DDoS attacks from consumers.  The principal attack a consumer

   may apply is to attempt to start multiple sessions either

   sequentially or simultaneously.  Protection can be applied by

   imposing rate limits.

 

   Additionally, it may be considered that the export of link-state and

   TE information as described in this document constitutes a risk to

   confidentiality of mission-critical or commercially sensitive

   information about the network.  BGP peerings are not automatic and

   require configuration; thus, it is the responsibility of the network

   operator to ensure that only trusted consumers are configured to

   receive such information.

 

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
Sent: Friday, October 19, 2018 1:29 PM
To: Susan Hares; 'Robert Raszuk'; kaduk@mit.edu
Cc: idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Sue –

 

Inline.

 

From: Susan Hares <shares@ndzh.com> 
Sent: Friday, October 19, 2018 10:08 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Robert Raszuk' <robert@raszuk.net>; kaduk@mit.edu
Cc: idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Les:

 

I apologize if my email message was unclear.   We both agree that your draft is not related to SR routing.   SR routing is related to BGP-LS as a transport mechanism for information.  

 

I agree that RFC7752 had traffic engineering information.  However, that traffic engineering information almost got that draft rejected by the IESG at the time.  As my previous message to this list indicated, we got agreement on RFC7752 based on limiting that information and the assurance that BGP-LS nodes were deployed on a separate set of nodes.  Expanding the traffic engineering information beyond RFC7752 re-opens all the security issues and questions from RFC7752’s original review.  

 

[Les:] So far, you are the only person who seems aware of this. I am not saying you are wrong – I am just saying my private attempts to get more context for this have thus far failed – and you have not provided any documentation of this.

If your statement is accurate (again – not saying it isn’t) – it also seems most unfortunate (and I am being “kind” here) that this was not mentioned in the course of the four years that draft-ietf-idr-te-pm-bgp has taken to progress to this point.

 

The security directorate reviewer is asking these security questions.  The security directorate does have people with both routing and security experts.   

 

SR routing is also expanding the information past the original RFC7752.   The expansions requested by SR routing also re-open those original security questions and issues.  

 

[Les:] I do not know why you mention SR here since we both agree this draft is not SR related.

 

One way to answer these questions is to provide a  RFC7752bis with an updated security section.  If you agree with this approach, I suggest simply referring to a RFC7752bis that in your security section.   If you disagree that an update to the RFC7752bis is required, we can start a thread on that point. 

 

[Les:] There is no RFC7752bis draft. J  So you are asking me to reference a non-existent document?

 

I understand that you (at least) would like to have one – which is perfectly legitimate – though you should go through the normal WG process to take this work on – correct?

 

But this dodges the question as to whether draft-ietf-idr-te-pm-bgp has a dependency on enhanced security. So far, you are the only person making this claim – and several folks (including myself) have expressed a different POV. I think you at least have to provide a justification for this dependency before we introduce it and get some support for your position – since this will mean draft-ietf-idr-te-pm-bgp would be stuck in MISSREF state until this currently non-existent draft becomes an RFC.

 

   Les

 

Did this message clarify my earlier brief message?  Do you want to continue to discuss the need for RFC7752bis? 

 

Cheerily, Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 10:58 AM
To: Susan Hares; 'Robert Raszuk'; kaduk@mit.edu
Cc: idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Sue –

 

One of us is confused. J

 

draft-ietf-idr-te-pm-bgp is not related to Segment Routing. Those words do not appear anywhere in the document. Nor is there a reference to any SR document.

 

Further, RFC 7752 includes traffic engineering information (see https://tools.ietf.org/html/rfc7752#section-3.3.2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7752-23section-2D3.3.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=RXx7h2EP_TUmNFxdSk6_WgQ27JsdivA22bqO3xxj63E&e=>  ) so the suggestion that we are introducing a new attack vector by defining some additional(sic) TE codepoints does not make sense to me.

 

I appreciate that there are other drafts on your mind which are SR related – but this is not one of them.

 

Could you please update your response with these points in mind?

 

Thanx.

 

   Les

 

 

From: Susan Hares <shares@ndzh.com> 
Sent: Friday, October 19, 2018 6:26 AM
To: 'Robert Raszuk' <robert@raszuk.net>; kaduk@mit.edu
Cc: ietf@ietf.org; secdir@ietf.org; ynir.ietf@gmail.com; idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Robert, Benjamin, and Yoav: 

 

I agree these context of these issues are not specific to this draft.  However, traffic engineering information does provide information which is a tempting attack vector. 

 

The original RFC7752 described a different purpose with restricted usage that SR routing extensions do not adhere to in BGP.   Since Spring WG shows that operators are interested in the extended use, it may be time to examine the RFC7752bis or other solutions that takes care of these security issues.  

 

My job as a shepherd is to point out these issues per draft for the IESG and security directorate in order to obtain the correct feedback.  As a WG chair, I have pointed out these issues, but the WG has these drafts on WG LC without the extra security.

Without RFC7752bis with additional security in the base document, I am working as a shepherd make the manageability and security sections as clear as possible.  

 

If the feedback from the security directorate review or the IESG is that we need to obtain a solution for RFC7752bis that describes and handles these security issues, I will be glad to support fast-tracking this issue within the WG. 

 

If an offline discussion with Benjamin, Yoav, the IDR chairs, and Alvaro would speed this along, I can set this up early next week.  It would be helpful to have this offline discussion before the IDR interim session on 10/26. 

 

Thank you for all your comments. 

 

Sue 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, October 19, 2018 2:52 AM
To: kaduk@mit.edu
Cc: ietf@ietf.org; secdir@ietf.org; ynir.ietf@gmail.com; idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

Hello Benjamin,

 

Not sure if you have spotted similar comment made to IDR regarding this topic, but your comment seems to indicate that here we are about to define ways to carry nicely scoped IGP information into BGP. Well that has already happened with RFC7752 and your comment or for that matter Yoav's remarks are indeed spot on but to the security discussion on RFC7752 and IMO not any follow up extensions of it. 

 

Sure - as observed by Sue - one may argue that providing more information about the network to the potential attacker makes the network weaker, but the cure for that is to prevent the leaks and reduce probability of intercepting new information by unauthorized parties. 

 

BGP-LS is already defined in a new SAFI what by itself does provide nice level of isolation. RFC7752 is pretty clear on that too and says: 

 

"BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information."

 

If someone would be still concerned about configuration mistakes and negotiating SAFI 71 or 72 to those who should not get this data I recommend we reissue the RFC7752 as -bis version and restrict the scope of the distribution even further by mandating default use of NO-EXPORT community with ability to overwrite it for the selective eBGP peers. Or perhaps we could progress Jim's One Administrative Domain draft (draft-uttaro-idr-oad-01). 

 

In either case while both of your comments are great they seems a bit late in the game here or at least targeting wrong document. 

 

Kind regards,

Robert.

 

 

On Fri, Oct 19, 2018 at 2:27 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

On Thu, Oct 18, 2018 at 06:00:13PM +0000, Les Ginsberg (ginsberg) wrote:
> Yoav –
> 
> In regards to the risks associated with advertising the specific information covered in this draft we have a statement in the IGP drafts:
> 
> From RFC7810
> 
> “The sub-TLVs introduced in this document allow an operator to
>    advertise state information of links (bandwidth, delay) that could be
>    sensitive and that an operator may not want to disclose.”
> 
> In regards to the risks associated with sending information via BGP-LS we have a number of statements in RFC 7752 – most relevant is:
> 
> “Additionally, it may be considered that the export of link-state and
>    TE information as described in this document constitutes a risk to
>    confidentiality of mission-critical or commercially sensitive
>    information about the network.”
> 
> So long as there are references to both the IGP RFCs and RFC 7752 I am therefore hard pressed to understand what else could be usefully said.
> Certainly the risks associated with the BGP-LS transport mechanism are not altered by adding some new TLVs – and since the IGP RFCs have already covered risks associated with the specific class of information (not simply the risks associated with the transport mechanism) you are going to have to provide more specifics on what can meaningfully be said that is not already covered in the references.

My apologies for jumping in in the middle, but IIUC the IGP RFCs have
covered the risks associated with a specific class of information, *under
the assumption that the transport mechanism is within a single AS and
administrative domain*.  Yoav is pointing out that the risks for that
information may change when the distribution is over a broader domain than
the one for which the previous analysis was performed.

-Ben