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