Re: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Tue, 30 July 2019 16:14 UTC

Return-Path: <rdd@cert.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55112015C; Tue, 30 Jul 2019 09:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 thdYh0wbNcto; Tue, 30 Jul 2019 09:14:24 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C8612016F; Tue, 30 Jul 2019 09:14:24 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6UGEMrm007843; Tue, 30 Jul 2019 12:14:23 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x6UGEMrm007843
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1564503263; bh=8K45KweEJLPRYc0lyf/swdMVnrutmWgu+3MzEd+FGqo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PSYqs3KWxUnYeG+964zy1cldaY3bx+jo5tlcoEyWbu1QkTWS+CyOaRgffKZhJkdFM r3ZCeTo1xWM7cCFoPW3wmYiT65qfqlzTMIkn0MnWSXjzvu8+LX5pvKIAScwgA3GaAe e+7jqH9nhksdcYW4Zp8qgU/mqDYQhsI4ahJ+LxGA=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6UGEELQ025394; Tue, 30 Jul 2019 12:14:14 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 12:14:14 -0400
From: Roman Danyliw <rdd@cert.org>
To: Yimin Shen <yshen@juniper.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mpls-egress-protection-framework@ietf.org" <draft-ietf-mpls-egress-protection-framework@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)
Thread-Index: AQHVNpIhEjfMhVXIGUGdYyoYSOUStKbHSeKAgA4HtvCABmswgIAHuO8A
Date: Tue, 30 Jul 2019 16:14:13 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33F083B@marchand>
References: <156270292067.15831.1558464118600381453.idtracker@ietfa.amsl.com> <F0304867-E97D-48EB-AC7D-525E84AE4199@juniper.net> <359EC4B99E040048A7131E0F4E113AFC01B33E2B56@marchand> <545CD971-1B38-47DA-85D9-A59C30297108@juniper.net>
In-Reply-To: <545CD971-1B38-47DA-85D9-A59C30297108@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lKGqrMq07LWhWiBOwT9epj4tE9c>
Subject: Re: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 16:14:27 -0000

Hi Yimin!

This revised addresses both of my discuss items.  Thank you synthesizing it.

Regards,
Roman

> -----Original Message-----
> From: Yimin Shen [mailto:yshen@juniper.net]
> Sent: Thursday, July 25, 2019 10:16 AM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-mpls-egress-protection-framework@ietf.org; Loa Andersson
> <loa@pi.nu>nu>; mpls-chairs@ietf.org; mpls@ietf.org
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-
> framework-06: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thanks again for your detailed review and comments! Please see below for
> the revised text which has incorporated your suggestions.
> 
> In particular, for your comment on the "In one possible case ..." about a CE-
> launched attack, this paragraph was added to address a comment from
> another view.  The case is not associated tightly with egress protection, but
> we thought it would be worth mentioning it, with a clarification that [1] such
> kind of attacks are not introduced by egress protection;  [2] they can happen
> regardless of egress protection; [3] there are existing mechanisms to deal
> with them. We have clarified more in the new text below.
> 
> Please let us know if you have more comment, or can resolve the discussion.
> Thanks again!
> 
> ----
> 
> 12.  Security Considerations
> 
>    The framework in this document involves rerouting traffic around an
>    egress node or link failure, via a bypass path from a PLR to a
>    protector, and ultimately to a backup egress router.
>    The forwarding performed by the routers in the data plane
>    is anticipated, as part of the planning of egress protection.
> 
>    Control plane protocols MAY be used to facilitate the provisioning of
>    the egress protection on the routers.  In particular, the framework requires
>    a service label distribution protocol between an egress router and a
> protector
>    over a secure session.  The security properties of this provisioning and label
>    distribution depend entirely on the underlying protocol chosen to
> implement
>    these activities . Their associated security considerations apply. This
> framework
>    introduces no new security requirements or guarantees relative to these
> activities.
> 
>    Also, the PLR, protector, and backup egress router are located close
>    to the protected egress router, and normally in the same
>    administrative domain.  If they are not in the same administrative
>    domain, a certain level of trust MUST be established between them in
>    order for the protocols to run securely across the domain
>    boundary.  The basis of this trust is the security model of the protocols
>    (as described above), and further security considerations for inter-domain
>    scenarios should be addressed by the protocols as a common requirement.
> 
>    Security attacks may sometimes come from a customer domain.
>    Such kind of attacks are not introduced by the framework
>    in this document, and may occur regardless of the existence of
>    egress protection. In one possible case, the egress link between an egress
>    router and a CE could become a point of attack.  An attacker that gains
> control
>    of the CE might use it to simulate link failures and trigger constant
>    and cascading activities in the network. If egress link protection is
>    in place, egress link protection activities may also be triggered.
>    As a general solution to defeat the attack, a damping mechanism
>    SHOULD be used by the egress router to promptly
>    suppress the services associated with the link or CE.  The egress
>    router would stop advertising the services, essentially detaching
>    them from the network and eliminating the effect of the simulated
>    link failures.
> 
>    From the above perspectives, this framework does not introduce any
>    new security threat to networks.
> 
> 
> Thanks,
> 
> -- Yimin
> 
> 
> 
> 
> 
> 
> On 7/23/19, 5:48 PM, "Roman Danyliw" <rdd@cert.org> wrote:
> 
>     Hi Yimin!
> 
>     > -----Original Message-----
>     > From: Yimin Shen [mailto:yshen@juniper.net]
>     > Sent: Friday, July 12, 2019 9:59 AM
>     > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
>     > Cc: draft-ietf-mpls-egress-protection-framework@ietf.org; Loa Andersson
>     > <loa@pi.nu>nu>; mpls-chairs@ietf.org; mpls@ietf.org
>     > Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-
> protection-
>     > framework-06: (with DISCUSS and COMMENT)
>     >
>     > Hi Roman,
>     >
>     > Thanks very much for your review!
>     >
>     > Please see inline below for the changes we plan to make, and let us
> know if
>     > they are sufficient to resolve this discussion.
>     >
>     > Thanks,
>     >
>     > -- Yimin
>     >
>     > On 7/9/19, 4:08 PM, "Roman Danyliw via Datatracker"
> <noreply@ietf.org>
>     > wrote:
>     >
>     >     Roman Danyliw has entered the following ballot position for
>     >     draft-ietf-mpls-egress-protection-framework-06: Discuss
>     >
>     >     When responding, please keep the subject line intact and reply to all
>     >     email addresses included in the To and CC lines. (Feel free to cut this
>     >     introductory paragraph, however.)
>     >
>     >
>     >     Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
>     > 3A__www.ietf.org_iesg_statement_discuss-
>     > 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
>     > ndb3voDTXcWzoCI&r=2-
>     >
> nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
>     >
> dZCH9iEG0x_yrqq45haf_Mseus&s=3coZyWz9ap2Zfz4Y4g17fpbs5CyIQnK3Oe
>     > cHx5BBXDE&e=
>     >     for more information about IESG DISCUSS and COMMENT positions.
>     >
>     >
>     >     The document, along with other ballot positions, can be found here:
>     >     https://urldefense.proofpoint.com/v2/url?u=https-
>     > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Degress-
> 2Dprotection-
>     > 2Dframework_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
>     > ndb3voDTXcWzoCI&r=2-
>     >
> nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
>     >
> dZCH9iEG0x_yrqq45haf_Mseus&s=6r9KW52kfdX1MRN_rfpiU1ILMNibzZh7u
>     > b-VcoEKCQM&e=
>     >
>     >
>     >
>     >     ----------------------------------------------------------------------
>     >     DISCUSS:
>     >     ----------------------------------------------------------------------
>     >
>     >     A few questions about the Security Considerations:
>     >
>     >     (1) Section 11.  I appreciate that this a framework document that is
> trying
>     > to
>     >     be generic.  Section 4 (and others) seem to lay out generic
> requirements.
>     >     However, this Security Considerations section is both vague on the
>     > protocol
>     >     choices (understandable) and the security services/properties they
> would
>     > have
>     >     (the gap).   For example, “The general security measures of the
> protocols
>     >     SHOULD be used whenever applicable.” and “The available security
>     > measures of
>     >     the chosen protocol SHOULD be used to achieve a secured session
>     > between the two
>     >     routers.”  Some discussion of what a “secured session” would look like
>     > would be
>     >     helpful.
>     >
>     > [yshen] We could say that “The general security measures of the
> protocols
>     > SHOULD be used whenever needed and applicable, e.g. an
> authentication
>     > method or password. The framework does not require additional
> security
>     > measures for these protocols, other than what they already have."
> 
>     Thanks.  I think I better understand what is meant with the text.  Correct
> me here, but it seems like you're saying that the security of establishing the
> egress protection behavior rests on the underlying security properties of the
> control plane/service label distribution protocols used to establish the it.
> Likewise, I'm assuming that the alluded alternative to using a control plan
> protocol (since the current text uses a MAY) is manual configuration.
> 
>     If my understanding is correct, might I suggest the following to make it
> clearer on what is in and out of scope:
> 
>     OLD:
>        Some control
>        plane protocols MAY be used between these routers to facilitate the
>        establishment of egress protection.  The general security measures of
>        the protocols SHOULD be used whenever applicable.  In particular, the
>        framework requires a service label distribution protocol between an
>        egress router and a protector.  The security measures of the chosen
>        protocol SHOULD be used to achieve a secured session between the two
>        routers.
> 
>     NEW
>     Control plane protocols MAY be used to facilitate the provisioning of this
> egress protection on the routers.  In particular, this framework requires a
> service label distribution protocol between an egress router and a protector
> over secure session.  The security properties of this provisioning and label
> distribution depend entirely on the underlying protocol chosen to
> implement these activities .  Their associated security considerations apply.
> This framework introduces no new security requirements or guarantees
> relative to these activities.
> 
>     >     (2) Section 11.  What are the elements and enablers of “a certain level
> of
>     >     trust … [being] established between the routers for the protocols to
> run
>     >     securely”?
>     >
>     > [yshen] Here, the "trust" simply means that, first the routers are allowed
> to
>     > run the protocols between them; and second, the protocols are run
> securely
>     > like the above. Again, this should be the same manner as that of an
> inter-AS
>     > protocols.
> 
>     Understood.  I believe we need a more detailed statement that (1) the
> basis of this trust is the security model of the selected protocols (like above);
> and a (paragraphing): "there security considerations for inter-AS protocols
> <as defined here> and they should be addressed by the implemented
> protocol".
> 
>     Finally, given what you've explained about the first two paragraphs, the
> second from last paragraph, "In one possible case ...",  seems to actually
> discuss a security issues relative to this framework.  Hence, I don't
> understand the basis of new last paragraph "From the above perspective,
> this framework doesn't introduce any new security threats to the network".
> 
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >
>     >     (3) Section 4.  Per “The framework MUST consider minimizing
> disruption
>     > during
>     >     deployment”, why is this MUST only to _consider_ minimizing rather
> than
>     >     actually minimizing the disruption?
>     >
>     > [yshen] Will change this to "This framework must minimize disruption
> ...".
>     > Also pointed out by some other viewers, the normative terms
>     > MAY/SHOULD/MUST are not suitable for this "consideration" section.
> Will
>     > replace them with may/should/must.
> 
>     Thanks.
> 
>     >     (4) Section 5.7.  Per “a globally unique IPv4/v6 address  is assigned to a
>     >     protected egress {E, P} as the identifier of the protected egress {E, P}”, I
>     >     recommend being explicit and saying and s/IPv4\\v6/IPv4 or v6/
>     >
>     > [yshen] Will fix this.
> 
>     Thanks.
> 
>     >     (5) Section 9.  I’m missing something obvious -- what is a “label table
>     >     pe2.mpls”?
>     >
>     > [yshen] I think you are talking about the example in section 10. As it
> specifies
>     > in the first paragraph, " On PE3, ....., and a table pe2.mpls is created to
>     > represent PE2's label space."
> 
>     We're talking about the same thing, the section titled "Example: Layer-3
> VPN egress protection" (it was section 9 in -05 and section 10 in -05).  I
> understand now.  Thank you for the clarification.
> 
>     Roman
> 
> 
>     >
> 
>