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:stephen.farr...@cs.tcd.ie] > Sent: Thursday, December 03, 2015 10:26 PM > To: The IESG > Cc: draft-ietf-bess-virtual-sub...@ietf.org; aret...@cisco.com; > bess-cha...@ietf.org; martin.vigour...@alcatel-lucent.com; bess@ietf.org > 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
