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

[Stephen Farrell <[e-mail]>]

Hiya,

On 07/12/15 03:15, Xuxiaohu wrote:
> Hi Stephen,
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[e-mail]] Sent: Friday, December 04, 2015
>> 7:40 PM To: Xuxiaohu; The IESG Cc:
>> [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail];
>> [e-mail] 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."


[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:[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
>>>>
>>>