> -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Friday, December 18, 2015 3:21 PM > To: Xuxiaohu; Alvaro Retana (aretana); The IESG > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > 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:[email protected]] Sent: Tuesday, December 15, 2015 > >> 5:00 PM To: Xuxiaohu; Alvaro Retana (aretana); The IESG Cc: > >> [email protected]; [email protected]; > >> [email protected]; [email protected] 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:[email protected]] Sent: Monday, December 14, > >>>> 2015 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG > >>>> Cc: [email protected]; > >>>> [email protected]; [email protected]; > >>>> [email protected] 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. > >>>>> > >>>>> _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
