Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)

Xuxiaohu <xuxiaohu@huawei.com> Fri, 18 December 2015 09:26 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD501B34D7; Fri, 18 Dec 2015 01:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 wMxGd1OzUSQ4; Fri, 18 Dec 2015 01:26:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6376F1B34D8; Fri, 18 Dec 2015 01:26:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFP69632; Fri, 18 Dec 2015 09:26:39 +0000 (GMT)
Received: from lhreml703-cah.china.huawei.com (10.201.5.104) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:26:37 +0000
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:26:37 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.64]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 17:26:32 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Alvaro Retana (aretana)" <aretana@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)
Thread-Index: AQHRLdaOLk8nhORYXUKrCN/X2riedp66D2jwgAAf9ICABKhN0IAAFESAgAsadwCAAAObAIABRkxQ///7zQCABQwf4P//jyyAgACaRjA=
Date: Fri, 18 Dec 2015 09:26:31 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB5622B@NKGEML512-MBS.china.huawei.com>
References: <20151203142601.21348.10762.idtracker@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB53D79@NKGEML512-MBS.china.huawei.com> <56617BAD.6070906@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB54209@NKGEML512-MBS.china.huawei.com> <566574D9.6030202@cs.tcd.ie> <D2942F48.F093A%aretana@cisco.com> <566EC84E.7070600@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB55473@NKGEML512-MBS.china.huawei.com> <566FD680.2060901@cs.tcd.ie> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB56196@NKGEML512-MBS.china.huawei.com> <5673B3C3.7020300@cs.tcd.ie>
In-Reply-To: <5673B3C3.7020300@cs.tcd.ie>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5673D151.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.64, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a31d151a71e39ce19f31b3d9f3ecb57d
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/LSReJP7E6H98kxEzPskS4aZ2UMk>
Cc: "draft-ietf-bess-virtual-subnet@ietf.org" <draft-ietf-bess-virtual-subnet@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "martin.vigoureux@alcatel-lucent.com" <martin.vigoureux@alcatel-lucent.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2015 09:26:47 -0000


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Friday, December 18, 2015 3:21 PM
> To: Xuxiaohu; Alvaro Retana (aretana); The IESG
> Cc: draft-ietf-bess-virtual-subnet@ietf.org; bess-chairs@ietf.org;
> martin.vigoureux@alcatel-lucent.com; bess@ietf.org
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with
> DISCUSS and COMMENT)
> 
> 
> 
> On 18/12/15 06:25, Xuxiaohu wrote:
> > Hi Stephen,
> >
> > Sorry for my late response. The reason that I hesitated to add MACsec
> > as an additional example of a strong security mechanism is as
> > follows: MACsec is a layer2 encryption mechanism and therefore it
> > seems not much suitable to protect IP encapsulated traffic between PE
> > routers, unless these PE routers are directly connected to each other
> > at Layer2.
> 
> My belief is that such a scenario can be the case for some inter-DC links. That's
> not based on real experience though so I'm open to correction. Hopefully,
> someone getting this mail knows the answer and can tell us if MACsec really is
> worth mentioning. (If not, I'm now curious enough to try go chase down the
> answer:-)
> 

Hi Stephen,

The following are some materials related to MACsec and MPLS VPN:

https://www.brocade.com/content/dam/common/documents/content-types/feature-guide/brocade-macsec-fg.pdf
http://www.juniper.net/techpubs/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-137-macsec-over-mpls-ccc-configuring.pdf

It shows that MACsec is mainly applicable to MPLS L2VPN scenarios such as VLL and VPLS rather than MPLS L3VPN.  Since this draft is based on MPLS L3VPN (i.e., MPLS/BGP IP VPN), it seems that we don't have to mention it as one ADDITIONAL example of a strong security mechanism. Is it fine for you?

Best regards,
Xiaohu

> > If my understand is wrong, would you please explain how to use MACsec
> > to protect the IP encapsulated traffic between PE routers which are
> > not directly connected? Or would you please provide me a link to some
> > RFC which talks about this usage?
> 
> I don't believe there is. At that point you have to go up the stack to MPLS-OS
> maybe, or IPsec. But the text does already cover this.
> 
> Cheers,
> S.
> 
> 
> >
> > Best regards, Xiaohu
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Tuesday, December 15, 2015
> >> 5:00 PM To: Xuxiaohu; Alvaro Retana (aretana); The IESG Cc:
> >> draft-ietf-bess-virtual-subnet@ietf.org; bess-chairs@ietf.org;
> >> martin.vigoureux@alcatel-lucent.com; bess@ietf.org Subject: Re:
> >> Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06:
> >> (with DISCUSS and COMMENT)
> >>
> >>
> >> Hiya,
> >>
> >> On 15/12/15 01:19, Xuxiaohu wrote:
> >>> Hi Stephen,
> >>>
> >>> It said "...using a strong security mechanism such as IPsec
> >>> [RFC4301]". Here IPsec is just mentioned as an example of a strong
> >>> security mechanism. Therefore, it doesn't exclude MACsec.
> >>
> >> Sure, but...
> >>
> >> The text that I suggested and that you said seemed good did include
> >> MACsec.
> >>
> >> On 09/12/15 07:47, Xuxiaohu wrote:
> >>>> So maybe something more like:
> >>>>
> >>>> "Inter data-centre traffic often carries highly sensitive
> >>>> information
> >> at higher
> >>>> layers that is not directly understood (parsed) within an egress or
> >>>> ingress PE. For example, migrating a VM
> >> will often
> >>>> mean moving private keys and other sensitive configuration
> >> information. For
> >>>> this reason inter data-centre traffic SHOULD always be protected
> >>>> for both confidentiality and integrity using a strong security
> >>>> mechanism such
> >> as IPsec [1]
> >>>> or MACsec [2] In future it may be feasible to protect that traffic
> >> within the MPLS
> >>>> layer [3] though at the time of writing the mechanism for that is
> >>>> not
> >> sufficiently
> >>>> mature to recommend. Exactly how such security mechanisms are
> >> deployed will
> >>>> vary from case to case, so securing the inter data-centre traffic
> >>>> may
> >> or may not
> >>>> involve deploying security mechanisms on the ingress/egress PEs or
> >> further
> >>>> "inside" the data centres concerned. Note though that if security
> >>>> is
> >> not deployed
> >>>> on the egress/ingress PEs there is a substantial risk that some
> >> sensitive traffic
> >>>> may be sent in clear and therefore be vulnerable to pervasive
> >> monitoring [4] or
> >>>> other attacks."
> >>>
> >>> Thanks a lot for your suggested text. If nobody object the above
> >>> text, I will add it in the next revision.
> >>>
> >>
> >> And indeed you added it all except for MACsec.
> >>
> >> And my question is not whether MACsec is excluded but rather why it
> >> was omitted, when afaik, it is what is most used for securing this
> >> particular kind of inter-DC traffic. (At least I believe that MACsec
> >> is what's most used there. If not, I'd be glad to know
> >> that.)
> >>
> >> So, why not include MACsec? Did someone object? If so, why? (And can
> >> you send a pointer to the WG list where that objection was raised so
> >> I can understand it better.)
> >>
> >> Thanks, S.
> >>
> >>
> >>>
> >>> Best regards, Xiaohu
> >>>
> >>>> -----Original Message----- From: Stephen Farrell
> >>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Monday, December 14,
> >>>> 2015 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG
> >>>> Cc: draft-ietf-bess-virtual-subnet@ietf.org;
> >>>> bess-chairs@ietf.org; martin.vigoureux@alcatel-lucent.com;
> >>>> bess@ietf.org Subject: Re: Stephen Farrell's Discuss on
> >>>> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Can someone say why the mention of MACsec wasn't included? As I
> >>>> understand it, MACsec is what's mostly usable for inter-DC security
> >>>> so omitting it seems like a bad idea (or perhaps I'm
> >>>> misinformed)
> >>>>
> >>>> Thanks, S.
> >>>>
> >>>> On 14/12/15 13:34, Alvaro Retana (aretana) wrote:
> >>>>> Stephen:
> >>>>>
> >>>>> Hi!
> >>>>>
> >>>>> Xiaohu posted an update that we hope addresses your concerns.
> >>>>> Pelase take a look.
> >>>>>
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Alvaro.
> >>>>>
> >>>>>