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

Yoav Nir <ynir.ietf@gmail.com> Wed, 17 October 2018 18:13 UTC

Return-Path: <ynir.ietf@gmail.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 A794F130E01; Wed, 17 Oct 2018 11:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WAyMLsdB93bt; Wed, 17 Oct 2018 11:13:56 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 023E6130DEF; Wed, 17 Oct 2018 11:13:53 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id y144-v6so3146611wmd.4; Wed, 17 Oct 2018 11:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hjz8lH7t8q+vWJyyP9M16xC0rGk2E5tEhPas+tppiA0=; b=s4gppmyOavNNwWiB1cSuOUzCaLgUhSvrk52A+goePytJyAeGA9Lol6HCiP+MyYGaXT KHU3+KyNNz11HcwMxS7y8npzEbeGRGt5T3cQzT8Z8/JaFBOu8uDynxMmQgI8CRiWNMW3 npNoQ03asDQcpqQcWwXhV1P+xEDzTqIEzDXK93ds2FAiUbDHk2DoGpHw4JXdUdA7CDfe xEcAvnmE9Qx0k+oV9RkpAXb3whzTEI0AlJrit4+mQ6/A5EOISYHRlPPlHXuhqDebdFq1 W3GYPHGn0SO4CR1IUsOg82+gKQVhqn/xDV/tcG2cvSyc+Aacv1BaglKS8i2O3CG0AYvx Eprw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hjz8lH7t8q+vWJyyP9M16xC0rGk2E5tEhPas+tppiA0=; b=VZ4S0XH9PBsP48XMUPUxY2bUoFn3IRpFVX4XmnzEAbEWyfupAzOb7Cen7yl6pUlFlK 6cEL98a9DcNdxgrKpRh8sAuQQddY5P8bkfeGvwhBkakVkx8pggjKeqNHqa4MXUPkMWu7 tV8r58PNucOF3iWRR8ukBbla/mCjlMdsRPKsKu+kr/1dkSjo5iIylS5M2tOgK4HjUiF8 Z9bZ/5dhAHhQ6YwUv0WJrMf4xxwiL9J2QdDfKB1vW2oZdW34QtKotk/oz69TZwPxxYOa K4s8ZL/IY8kXDCZoFulVfgT8A7L8lQLBcZFWo7jIwOvbiEcLjKVzLB3qjgTecVX29Hx1 nUGQ==
X-Gm-Message-State: ABuFfoiJbuofqtO5onsR7M6qMkAObSAhJf8DtY2SYi52rrWEAEqwHTgs MdNHC6AwOMpJv78EftwtRN0=
X-Google-Smtp-Source: ACcGV6310RL9ndwrenvqsTAgOR2Bf3IxU7Yy1yeElVXLJpeaJ5pwvtSDXRQ1zXtnQi/8cT3kL/J+uw==
X-Received: by 2002:a1c:ed07:: with SMTP id l7-v6mr3934304wmh.47.1539800031372; Wed, 17 Oct 2018 11:13:51 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 199-v6sm1505928wme.39.2018.10.17.11.13.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Oct 2018 11:13:50 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <7655493D-9EF0-42FF-B2D3-B9CE4E78178D@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08A44EF3-9DA9-4B04-8A18-4A3E07AA7054"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 17 Oct 2018 21:13:47 +0300
In-Reply-To: <ec43e712e8024930831a206f8e843cbb@XCH-ALN-001.cisco.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-idr-te-pm-bgp.all@ietf.org" <draft-ietf-idr-te-pm-bgp.all@ietf.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
References: <153972468642.9298.14442375581871750001@ietfa.amsl.com> <ec43e712e8024930831a206f8e843cbb@XCH-ALN-001.cisco.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_abOrsJzJugZaeqDYkRLLo3eGeg>
Subject: Re: [secdir] 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: Wed, 17 Oct 2018 18:13:59 -0000

Hi, Les.

I agree that my diagram comment is directed mostly at 7752. However, the RFCs that we produce are intended to be readable by the general technical community, not just the experts in the working group. For the same reason that we are required to expand acronyms on first use, I think it makes sense for a document that describes new information being sent to identify the target. I will drop this point, though, because it is a general comment rather than a secdir issue.

I agree about not needing to repeat information that is already stated elsewhere, but you do need to point to it, as you do with the general security model of BGP (first paragraph), and as you do with the paragraph describing how the transport of attributes is secured (second paragraph). That part is fine. 

RFC 7810 and 7471 describe the new information to be sent, but they are about IS-IS and OSPF. The Security considerations section in 7810 contains the following text: "It is anticipated that in most deployments, the IS-IS protocol is used within an infrastructure entirely under control of the same operator.” and continues to discuss MITM attacks if this is not the case.  Can the same assumption be made about BGP?  That is the part that I think is missing. Either state that where BGP-LS is used the assumption can be made, or justify why there is no risk even when the information is propagated to infrastructure that is not under control of a single operator.   The difference between BGP and either IS-IS or OSPF is not part of those other documents, so IMO it should be stated here.

Yoav

> On 17 Oct 2018, at 2:52, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> Yoav -
>  
> Thanx for the review.
>  
> I'll preface my remarks by saying I am a big believer in modularity. If a referenced document has already covered an issue I strongly believe we are better off referencing that document than trying to repeat/restate what the referenced document has said.
> There are only two things that can happen when we repeat/restate:
>  
> 1)We are redundant
> 2)We introduce ambiguity
>  
> Neither of these is desirable.
>  
> Responses inline.
>  
> > -----Original Message-----
> > From: Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>
> > Sent: Tuesday, October 16, 2018 2:18 PM
> > To: secdir@ietf.org <mailto:secdir@ietf.org>
> > Cc: idr@ietf.org <mailto:idr@ietf.org>; ietf@ietf.org <mailto:ietf@ietf.org>; draft-ietf-idr-te-pm-bgp.all@ietf.org <mailto:draft-ietf-idr-te-pm-bgp.all@ietf.org>
> > Subject: Secdir early review of draft-ietf-idr-te-pm-bgp-13
> >
> > Reviewer: Yoav Nir
> > Review result: Has Nits
> >
> > This is an early review with a specific request to review the Security
> > Considerations section.
> >
> > The draft adds a bunch of TLVs to be sent from routers regarding the link
> > state of the link used for IGP. The draft references RFC 7752 which defined
> > earlier TLVs used to carry NLRI (reachability) information.
> >
> > What I found difficult about both 7752 and this draft is the vagueness about
> > who the consumer of this information is. The abstract of 7752 begins like this:
> > "In a number of environments, a component external to a network is called
> > upon to perform computations based on the network topology and current
> > state of the connections within the network, including Traffic Engineering
> > (TE) information." There is also a diagram with information flowing to a
> > "consumer"
> > and that's it. Is it an SDN controller? Some kind of application?
> >
>  
> [Les:] The diagram you are referring to seems most likely to be in RFC 7752 since there is no such diagram in this draft.
> Which leads me to say if you feel this is insufficient then it needs to be taken up in the context of RFC 7752 - not this draft.
>  
> Hopefully this makes sense to you as well.
>  
> > OK. On to the Security Considerations section. It begins with a statement that
> > this does not affect the security model of BGP.  Although that is just claimed
> > and not supported in text, it seems reasonable. I should note that this
> > paragraph is copied from 7752.
> >
> > The second (and last) paragraph in the security considerations section talks
> > about the new attributes. It mentions that security and authentication are
> > assumed to be used just as in RFCs 7810 and 7471. With proper
> > authentication this information is not sent except to the proper consumer.
> > However, there is an important difference that I think needs to be
> > addressed. 7810 and 7471 are about IS-IS and OSPF respectively. There
> > routing protocols are typically used in closed environments, and the Security
> > Considerations of 7810 state that explicitly. BGP (the subject of this
> > document) is different in that it is typically used all over the Internet. Without
> > further clarity about who and where the "consumer" is, it has to be assumed
> > that the information might at least leak out.
> > 
> [Les:] I think you have misinterpreted this paragraph. (emphasis added below)
>  
> " The IGP
>    instances originating these TLVs are assumed to have all the required
>    security and authentication mechanism (as described in [RFC7810] and
>    [RFC7471]) in order to prevent any security issue when propagating
>    the TLVs into BGP-LS."
>  
> What we are stating here is that when the IGP advertisements are sent the security/authentication mechanisms specified in the IGP drafts applies.
> This is NOT trying to apply RFC7810/RFC7471 to the new BGP advertisements.
> The security issues related to the new BGP advertisements are discussed in the previous paragraph.
>  
> > Another issue I have with this section is that the draft specifies how to send
> > new information (the link state TLVs) from one node to another. This is
> > information that was not sent before. When a change like that is made, I
> > think the Security Considerations section should justify why it is OK to
> > distribute this information. Typically you need to justify that leaking this
> > information (to the intended recipient or to the rest of the world) does not
> > (1) make it easier to attack some part of the system, or (2) distributes
> > privacy-sensitive information, or (3) undermines some other confidentiality
> > interest. I think it's fairly easy to make the argument that the information in
> > these TLVs does not do any of the above, but the argument should be made.
> > The last paragraph in the Security Considerations section of RFC 7752 has just
> > such an argument.
>  
> [Les:] Security sections in RFC7810/RFC7471 directly address this point.
> WE could repeat some of that here – but as per my “opening statement” I am reluctant to do so.
>  
> What do you think?
>  
>    Les