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

[Stephen Farrell <[e-mail]>]

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:[e-mail]] Sent: Thursday, December 03,
>> 2015 10:26 PM To: The IESG Cc:
>> [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail];
>> [e-mail] 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
>> 
>