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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 03 Dec 2015 06:26:01 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-bess-virtual-subnet-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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Surely extending a subnet from one to many data centres should
only be done if inter-data-centre traffic is all encrypted and
authenticated? I don't get why there isn't a MUST-like statement
here for such protection, and going a bit further, why some
interoperable form of protection for such traffic (e.g. IPsec,
MACsec) isn't recommended as being MTI in such cases. The huge
variety of potentially and actually sensitive traffic being handled
by VMs these days and which ought not be, and probably is not,
understood by folks doing routing seems to very strongly imply that
such protection should in fact be turned on all of the time. (But
stating that would be going beyond current IETF consenus on MTI
security as expressed in BCP61.  It'd still be a good idea I think
though.)

(2) I'm guessing one reaction to the above discuss point could be
"sure, but this is the wrong document." In that case, please show me
the right document and then tell me why a reference to that is not
needed here.

Note: none of the above is about RFC2119 MUST/SHOULD etc terms 
even though I use them above. Just normal english that makes the
point would be fine.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The secdir-review [1] raised a similar issue, but I don't think
the response to that is sufficient really. (The secdir reviewer
did think so.)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 4 Dec 2015 02:08:28 +0000

Hi Stephen,

Thank a lot for your DISCUSS. I fully agree with you that sensitive traffic being handled by VMs should be encrypted when traversing across the Internet or even SP networks. Similarly, I think you would also agree that sensitive traffic of VPN clients should be encrypted as well in the existing MPLS/BGP IP VPN [RFC4364] scenario. Hence, the security requirement should be the same for RFC4364 and this draft, IMHO. Therefore, in the Security Consideration section of this draft, it said " Since the BGP/MPLS IP VPN signaling is reused without any change, those security considerations as described in [RFC4364] are applicable to this document. " 

Any further comments are more than welcome.

Best regards,
Xiaohu

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, December 03, 2015 10:26 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with
> DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> (1) Surely extending a subnet from one to many data centres should only be
> done if inter-data-centre traffic is all encrypted and authenticated? I don't get
> why there isn't a MUST-like statement here for such protection, and going a bit
> further, why some interoperable form of protection for such traffic (e.g. IPsec,
> MACsec) isn't recommended as being MTI in such cases. The huge variety of
> potentially and actually sensitive traffic being handled by VMs these days and
> which ought not be, and probably is not, understood by folks doing routing
> seems to very strongly imply that such protection should in fact be turned on all
> of the time. (But stating that would be going beyond current IETF consenus on
> MTI security as expressed in BCP61.  It'd still be a good idea I think
> though.)
> 
> (2) I'm guessing one reaction to the above discuss point could be "sure, but this
> is the wrong document." In that case, please show me the right document and
> then tell me why a reference to that is not needed here.
> 
> Note: none of the above is about RFC2119 MUST/SHOULD etc terms even
> though I use them above. Just normal english that makes the point would be
> fine.
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 11:40:29 +0000

Hiya,

On 04/12/15 02:08, Xuxiaohu wrote:
> Hi Stephen,
> 
> Thank a lot for your DISCUSS. I fully agree with you that sensitive
> traffic being handled by VMs should be encrypted when traversing
> across the Internet or even SP networks. Similarly, I think you would
> also agree that sensitive traffic of VPN clients should be encrypted
> as well in the existing MPLS/BGP IP VPN [RFC4364] scenario. Hence,
> the security requirement should be the same for RFC4364 and this
> draft, IMHO. Therefore, in the Security Consideration section of this
> draft, it said " Since the BGP/MPLS IP VPN signaling is reused
> without any change, those security considerations as described in
> [RFC4364] are applicable to this document. "
> 

Well, my further comment is that the above doesn't seem adequate
at this point in time (to me:-)

In 2006, the security considerations of RFC4364 said:

" Cryptographic privacy is not provided by this architecture, nor by
   Frame Relay or ATM VPNs.  These architectures are all compatible with
   the use of cryptography on a CE-CE basis, if that is desired.

   The use of cryptography on a PE-PE basis is for further study."

In 2015, we know that people, can, should, and do, turn on crypto
between data centres.

Today's situation is not 2006's and that I think needs to be stated
and this document seems like a fine place to do that. I would still
think that were the statement clearly made elsewhere.

Cheers,
S.

> 
> Best regards, Xiaohu
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Thursday, December 03,
>> 2015 10:26 PM To: The IESG Cc:
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked];
>> [email-masked] Subject: Stephen Farrell's Discuss on
>> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT)
>> 
>> 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://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> done if inter-data-centre traffic is all encrypted and
>> "sure, but this is the wrong document." In that case, please show
>> me the right document and then tell me why a reference to that is
>> not needed here.
>> 
>> the response to that is sufficient really. (The secdir reviewer did
>> think so.)
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html
>> 
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 7 Dec 2015 03:15:29 +0000

Hi Stephen,

> Sent: Friday, December 04, 2015 7:40 PM
> To: Xuxiaohu; The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-bess-virtual-subnet-06: (with
> DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> > as well in the existing MPLS/BGP IP VPN [RFC4364] scenario. Hence, the
> > security requirement should be the same for RFC4364 and this draft,
> > IMHO. Therefore, in the Security Consideration section of this draft,
> > it said " Since the BGP/MPLS IP VPN signaling is reused without any
> > change, those security considerations as described in [RFC4364] are
> > applicable to this document. "
> >
> Well, my further comment is that the above doesn't seem adequate at this point
> in time (to me:-)
> 
> In 2015, we know that people, can, should, and do, turn on crypto between
> data centres.
> 
> Today's situation is not 2006's and that I think needs to be stated and this
> document seems like a fine place to do that. I would still think that were the
> statement clearly made elsewhere.

How about adding the following text into the current security consideration:

"The use of cryptography on a PE-PE basis is related to the specific tunnel technology which is used between PEs. For instance, if MPLS LSPs are used between PE routers, the approach as described in (https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-00) should be considered, and if IP-base tunnels for transporting MPLS are used between PE routers, those IP-based tunnels should be secured with IPsec or DTLS (for more details, please refer to the corresponding specification of a particular IP-based tunnel technology). Of course, if the data traffic has been encrypted before arriving at the ingress PE, the use of cryptography on a PE-PE basis may not be necessary any more."

Best regards,
Xiaohu

> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> done if inter-data-centre traffic is all encrypted and authenticated?
> >> I don't get why there isn't a MUST-like statement here for such
> >> protection, and going a bit further, why some interoperable form of
> >> protection for such traffic (e.g. IPsec,
> >> though I use them above. Just normal english that makes the point
> >> would be fine.
> >>
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 12:00:25 +0000

Hiya,

On 07/12/15 03:15, Xuxiaohu wrote:
>> [mailto:[email-masked]] Sent: Friday, December 04, 2015
>> 7:40 PM To: Xuxiaohu; The IESG Cc:
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked];
>> [email-masked] Subject: Re: Stephen Farrell's Discuss on
>>> Thank a lot for your DISCUSS. I fully agree with you that
>>> sensitive traffic being handled by VMs should be encrypted when
>>> traversing across the Internet or even SP networks. Similarly, I
>>> think you would also agree that sensitive traffic of VPN clients
>>> should be encrypted as well in the existing MPLS/BGP IP VPN
>>> [RFC4364] scenario. Hence, the security requirement should be the
>>> same for RFC4364 and this draft, IMHO. Therefore, in the Security
>>> Consideration section of this draft, it said " Since the BGP/MPLS
>>> IP VPN signaling is reused without any change, those security
>>> considerations as described in [RFC4364] are applicable to this
>>> document. "
>>> 
>> Well, my further comment is that the above doesn't seem adequate at
>> this point in time (to me:-)
>> 
>> " Cryptographic privacy is not provided by this architecture, nor
>> by Frame Relay or ATM VPNs.  These architectures are all compatible
>> with the use of cryptography on a CE-CE basis, if that is desired.
>> 
> "The use of cryptography on a PE-PE basis is related to the specific
> tunnel technology which is used between PEs. For instance, if MPLS
> LSPs are used between PE routers, the approach as described in
> (https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-00)
> should be considered, and if IP-base tunnels for transporting MPLS
> are used between PE routers, those IP-based tunnels should be secured
> with IPsec or DTLS (for more details, please refer to the
> corresponding specification of a particular IP-based tunnel
> technology). Of course, if the data traffic has been encrypted before
> arriving at the ingress PE, the use of cryptography on a PE-PE basis
> may not be necessary any more."

That's definitely along the right lines but I think needs a few
tweaks...

First, even though I'm an author I think you're putting too much
emphasis on the MPLS-OS stuff - we don't honestly know (yet) if
that is something that'll see real deployment. And I'm told MACsec
is also used for DC-DC security so referencing it as well as
IPsec would be good.

I'm not sure what DTLS based mechanism can be referenced here
though one could of course exist or be defined in future. I'd
say if there's no good reference for such, then maybe that's
best omitted for now. If there's a
goohttps://tools.ietf.org/html/rfc7258d reference then adding
it would be good.

And your text also avoids recommending securing traffic between
data centres, which I think is needed, and is the main point for
this text (for this informational document).

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."

[1] https://tools.ietf.org/html/rfc4301
[2] http://www.ieee802.org/1/pages/802.1ae.html
[3] https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt
[4] https://tools.ietf.org/html/rfc7258

Note - I'm not sure if [2] is the best reference for MACsec,
but I bet some of you will know better.

If you want to s/SHOULD/MUST/ above I'd be fine with that.
And if this document isn't using 2119 terminology (I forget)
that's also fine just s/SHOULD/should/ (or "must":-).

Cheers,
S.

>> Cheers, S.
>>>> [mailto:[email-masked]] Sent: Thursday, December
>>>> 03, 2015 10:26 PM To: The IESG Cc: 
>>>> 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://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
---------------------------------------------------------------------
>>>> -
>>>> 
>>>> 
>> DISCUSS:
>>>> ---------------------------------------------------------------------
>>>>
>>>> 
-
>> only be
>>>> authenticated? I don't get why there isn't a MUST-like
>>>> statement here for such protection, and going a bit further,
>>>> why some interoperable form of protection for such traffic
>>>> (e.g. IPsec, MACsec) isn't recommended as being MTI in such
>>>> cases. The huge variety of potentially and actually sensitive
>>>> traffic being handled by VMs these days and which ought not be,
>>>> and probably is not, understood by folks doing routing seems to
>>>> very strongly imply that such protection should in fact be
>>>> turned on all of the time. (But stating that would be going
>>>> beyond current IETF consenus on MTI security as expressed in
>>>> BCP61.  It'd still be a good idea I think though.)
>>>> 
>>>> (2) I'm guessing one reaction to the above discuss point could
>>>> be "sure, but this is the wrong document." In that case, please
>>>> show me the right document and then tell me why a reference to
>>>> that is not needed here.
>>>> 
>>>> even though I use them above. Just normal english that makes
>>>> the point would be fine.
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>>
>>>> 
-
>>>> 
>>>> 
>> COMMENT:
>>>> ---------------------------------------------------------------------
>>>>
>>>> 
-

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 9 Dec 2015 07:47:48 +0000

Hi Stephen,

> Sent: Monday, December 07, 2015 8:00 PM
> To: Xuxiaohu; The IESG
> >> Subject: Re: Stephen Farrell's Discuss on
> >>> across the Internet or even SP networks. Similarly, I think you
> >>> would also agree that sensitive traffic of VPN clients should be
> >>> encrypted as well in the existing MPLS/BGP IP VPN [RFC4364]
> >>> scenario. Hence, the security requirement should be the same for
> >>> RFC4364 and this draft, IMHO. Therefore, in the Security
> >>> Consideration section of this draft, it said " Since the BGP/MPLS IP
> >>> VPN signaling is reused without any change, those security
> > should be considered, and if IP-base tunnels for transporting MPLS are
> > used between PE routers, those IP-based tunnels should be secured with
> > IPsec or DTLS (for more details, please refer to the corresponding
> > specification of a particular IP-based tunnel technology). Of course,
> > if the data traffic has been encrypted before arriving at the ingress
> > PE, the use of cryptography on a PE-PE basis may not be necessary any
> > more."
> 
> That's definitely along the right lines but I think needs a few tweaks...
> 
> First, even though I'm an author I think you're putting too much emphasis on
> the MPLS-OS stuff - we don't honestly know (yet) if that is something that'll see
> real deployment. And I'm told MACsec is also used for DC-DC security so
> referencing it as well as IPsec would be good.
> 
> I'm not sure what DTLS based mechanism can be referenced here though one
> could of course exist or be defined in future. I'd say if there's no good reference
> for such, then maybe that's best omitted for now. If there's a
> goohttps://tools.ietf.org/html/rfc7258d reference then adding it would be
> good.
> 
> And your text also avoids recommending securing traffic between data centres,
> which I think is needed, and is the main point for this text (for this informational
> document).
> 
> "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.

Best regards,
Xiaohu

> Note - I'm not sure if [2] is the best reference for MACsec, but I bet some of you
> will know better.
> 
> And if this document isn't using 2119 terminology (I forget) that's also fine just
> s/SHOULD/should/ (or "must":-).
> 
> Cheers,
> S.
> 
> 
> 
> 
> >
> > Best regards, Xiaohu
> >
> >> Cheers, S.
> >>
> >>
> >>>
> >>> Best regards, Xiaohu
> >>>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 14 Dec 2015 13:34:00 +0000

Stephen:

Hi!

Xiaohu posted an update that we hope addresses your concerns.  Pelase take
a look.

Thanks!

Alvaro.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Dec 2015 13:46:54 +0000

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.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Dec 2015 01:19:10 +0000

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.

Best regards,
Xiaohu

> Sent: Monday, December 14, 2015 9:47 PM
> To: Alvaro Retana (aretana); Xuxiaohu; The IESG
> [email-masked]; [email-masked]
> 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.
> 
> > Xiaohu posted an update that we hope addresses your concerns.  Pelase
> > take a look.
> >
> >
> > Thanks!
> >
> > Alvaro.
> >
> >

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2015 08:59:44 +0000

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:
> 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.

>> [mailto:[email-masked]] Sent: Monday, December 14, 2015
>> 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG Cc:
>> [email-masked]; [email-masked] 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.
>> 
>>> Xiaohu posted an update that we hope addresses your concerns.
>>> Pelase take a look.
>>> 
>>> 
>>> Thanks!
>>> 
>>> Alvaro.
>>> 
>>>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Dec 2015 06:25:43 +0000

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. 

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?

Best regards,
Xiaohu

> Sent: Tuesday, December 15, 2015 5:00 PM
> To: Xuxiaohu; Alvaro Retana (aretana); The IESG
> The text that I suggested and that you said seemed good did include MACsec.
> 
> >> this reason inter data-centre traffic SHOULD always be protected for
> >> both confidentiality and integrity using a strong security mechanism
> >> such
> as IPsec [1]
> 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.)
> 
> (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
> >

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Dec 2015 07:20:35 +0000

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:-)

> 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.

>> [mailto:[email-masked]] Sent: Tuesday, December 15, 2015
>> 5:00 PM To: Xuxiaohu; Alvaro Retana (aretana); The IESG Cc:
>>> [RFC4301]". Here IPsec is just mentioned as an example of a
>>> strong security mechanism. Therefore, it doesn't exclude MACsec.
>> 
>> Sure, but...
>> 
>>>> information
>> at higher
>>>> layers that is not directly understood (parsed) within an
>>>> egress or ingress PE. For example, migrating a VM
>> will often
>>>> 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
>>>> 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
>>> Thanks a lot for your suggested text. If nobody object the above
>>> text, I will add it in the next revision.
>>> 
>> 
>> 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
>> 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
>>> 
>>>> [mailto:[email-masked]] Sent: Monday, December 14,
>>>> 2015 9:47 PM To: Alvaro Retana (aretana); Xuxiaohu; The IESG
>>>> Cc: [email-masked];
>>>> [email-masked] Subject: Re: Stephen Farrell's Discuss on
>>>> 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.
>>>> 
>>>>> Xiaohu posted an update that we hope addresses your
>>>>> concerns. Pelase take a look.
>>>>> 
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Alvaro.
>>>>> 
>>>>>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Dec 2015 09:26:31 +0000

> Sent: Friday, December 18, 2015 3:21 PM
> 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

> 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
> >
> >>>> layers that is not directly understood (parsed) within an egress or
> >>>> ingress PE. For example, migrating a VM
> >> will often
> >>>> this reason inter data-centre traffic SHOULD always be protected
> >>>> for both confidentiality and integrity using a strong security
> >>>> mechanism such
> >> as IPsec [1]
> >>>> layer [3] though at the time of writing the mechanism for that is
> >>>> not
> >> sufficiently
> >>>> vary from case to case, so securing the inter data-centre traffic
> >>>> may
> >> or may not
> >>>> "inside" the data centres concerned. Note though that if security
> >>>> is
> >> not deployed
> >> 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
> >>>