Hi Stephen, > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Monday, December 07, 2015 8:00 PM > To: Xuxiaohu; The IESG > Cc: [email protected]; [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 07/12/15 03:15, Xuxiaohu wrote: > > Hi Stephen, > > > >> -----Original Message----- From: Stephen Farrell > >> [mailto:[email protected]] Sent: Friday, December 04, 2015 > >> 7:40 PM To: Xuxiaohu; The IESG Cc: > >> [email protected]; [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 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. " > >>> > >>> Any further comments are more than welcome. > >> > >> 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. > > > > 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." > > 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."
Thanks a lot for your suggested text. If nobody object the above text, I will add it in the next revision. Best regards, Xiaohu > > [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. > > > > > > > > Best regards, Xiaohu > > > >> Cheers, S. > >> > >> > >>> > >>> Best regards, Xiaohu > >>> > >>>> -----Original Message----- From: Stephen Farrell > >>>> [mailto:[email protected]] Sent: Thursday, December 03, > >>>> 2015 10:26 PM To: The IESG Cc: > >>>> [email protected]; [email protected]; > >>>> [email protected]; [email protected]; > >>>> [email protected] Subject: Stephen Farrell's Discuss on > >>>> draft-ietf-bess-virtual-subnet-06: (with DISCUSS and COMMENT) > >>>> > >>>> 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 > >>>> > >>> _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
