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