Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09

Huaimo Chen <huaimo.chen@huawei.com> Thu, 22 February 2018 21:46 UTC

Return-Path: <huaimo.chen@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4404C12D950; Thu, 22 Feb 2018 13:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 6D9TF7Y42OIx; Thu, 22 Feb 2018 13:46:02 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5B3A012420B; Thu, 22 Feb 2018 13:46:02 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EAFF27615A615; Thu, 22 Feb 2018 21:45:57 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 21:45:59 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Thu, 22 Feb 2018 13:45:56 -0800
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-teas-rsvp-egress-protection.all@ietf.org" <draft-ietf-teas-rsvp-egress-protection.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
Thread-Index: AQHTqnAoz+h2spacWkiZ4uzsCmYfVaOwjCSg
Date: Thu, 22 Feb 2018 21:45:55 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463A52635@sjceml521-mbs.china.huawei.com>
References: <151914767152.4003.2724168782038044771@ietfa.amsl.com>
In-Reply-To: <151914767152.4003.2724168782038044771@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.155.146]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/IB9SdEvJZ0YnX08CRZzC1Wv3H3g>
Subject: Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 21:46:04 -0000

Hi Rifaat,

    Thank you much for your time and your valuable comments.
    Answers to your questions are inline below with prefix [HC].
    Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-----Original Message-----
From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] 
Sent: Tuesday, February 20, 2018 12:28 PM
To: secdir@ietf.org
Cc: draft-ietf-teas-rsvp-egress-protection.all@ietf.org; ietf@ietf.org; teas@ietf.org
Subject: Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09

Reviewer: Rifaat Shekh-Yusef
Review result: Has Issues

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.

   "A backup egress MUST be configured on the ingress of an LSP to
   protect a primary egress of the LSP if and only if the backup egress
   is not indicated in another place."

Can you define "another place"? Is it the "primary egress"? others?
 
[HC] Yes. Another place in this context is the primary egress. 
We will update the document accordingly as below:
   "A backup egress MUST be configured on the ingress of an LSP to
   protect a primary egress of the LSP if and only if the backup egress
   is not configured on the primary egress."



   "To protect a primary egress of an LSP, a backup egress MUST be
   configured on the primary egress of the LSP to protect the primary
   egress if and only if the backup egress is not indicated in another
   place."   

Can you define "another place"? Is it the "ingress"? others?
   
[HC] Yes. Another place in this context is the ingress. 
We will update the document accordingly as below:
   "To protect a primary egress of an LSP, a backup egress MUST be
   configured on the primary egress of the LSP to protect the primary
   egress if and only if the backup egress is not configured on the 
   ingress."



   "Note that protecting a primary egress of a P2P LSP carrying service
   traffic through a backup egress requires that the backup egress trust
   the primary egress for the information received for a service label
   as UA label."
   
Can you elaborate on this statement? 
How would the backup egress trust the primary egress?

[HC] The information may be sent to the backup egress from the 
"primary egress" through another protocol such as BGP. The backup egress
need to  make sure that the "primary egress" that another protocol uses 
is the same primary egress to be protected. 
The backup egress may check whether the remote end of the BGP session 
is the primary egress if BGP is used to send the information to the 
backup egress from the "primary egress".
We will update the document accordingly as below:
  "Note that protecting a primary egress of a P2P LSP carrying service
   traffic through a backup egress requires that the backup egress make
   sure that the "primary egress" sending the backup egress the information 
   on a service label as UA label through another protocol such as BGP is 
   the same primary egress to be protected."


Regards,
 Rifaat