Re: [Teas-ns-dt] Security, and especially encryption.

[Jeff Tantsura <[e-mail]>]

Eric,

Please see inline, I see very little relevance to the questions asked though.
Note - I do work/advise daily with real customers, some of them are larger financials in the US that deal with the below as part of their service delivery, not some theoretical exercise!

Cheers,
Jeff
On May 14, 2020, 2:47 PM -0700, Eric Gray <[e-mail]>om>, wrote:
> Actually, Jeff, a user that truly wants to ensure that they get disjoined paths can easily determine that they got at least the appearance of disjoined paths because they get multiple separate service terminations. One technique that has been used was to buy separate services from separate providers, and even that did not always work if multiple providers share common lower-tier services.
>
> [jeff] This makes no sense technologically. We are not talking appearances but legal obligation that is covered by the agreement signed between provider and consumer. I’m not sure how this example is relevant though
>
> Asking for disjoined paths from a single provider reduces this risk, but not to zero. So, what you get is what the provider can offer with some reasonable confidence based on reasonable and practical due diligence in checking it out in advance.
>
> [jeff] what’s your point? If I have a 50MW DC and ask you for disjoined fibers, I’m not “reasonably confident”, I’m 100% confident, and pay accordingly, and if god forbid you have lied to me, I’ll sue you to death, no other DC owner will ever purchase from you
>
> But that is a separate discussion. As are a few other things in your reply.
>
> If a provider is required – by law – to provide encryption for certain cases, then of course they must provide it (in order to be compliant). The terms of that encryption are dictated by regulatory authority and established (in many cases) as determined via negotiation between the regulatory authority and the provider (up to and including exemption from meeting the requirement). The “user” does not have to request encryption, nor would it matter if they were to try to specify encryption, methods that differ from those established in the agreement between the provider and the regulatory authority.
>
> [jeff] This is user responsibility to comply with the regulations, as well as do due diligence to their abilities, and this is the user who is going to be fined/prosecuted if they don’t comply with the regulations.
>
> If you wish to assert that encryption is a Boolean service that is either provided or it is not, then – often the time – it is not. If the end user expects the provider to encrypt their data traffic, then that encryption must necessarily occur in equipment owned/operated by the provider. That equipment will have all of the vulnerabilities of any other equipment (vulnerable to insider attack, unauthorized traffic replication, recording or “scraping,” encryption hardware failure, etc.) – with the additional vulnerability of not being under the control of the entity who is expecting their data to be protected.
>
> [jeff] what’s your point?
>
> There are ways to improve the degree of confidence in the data protection provided (I mentioned at least a few in the mail below) and – whenever that is the case – then it must also be the case that there is at least the possibility that the confidence level in encryption is less than 100% (it is obvious that you cannot improve on a confidence of 100%).
>
> In this you are conflating “data protection” with availability, because – if a provider has the means to determine if there is a data protection failure, and data protection is an explicit requirement of the service – then the provider should terminate the service, making it clearly unavailable.
>
> [jeff] Yes, indeed, this is very simple, if the data is not protected the service is deemed unavailable (doesn’t meet constrains that define the service.
>
> To illustrate the “confidence factor” further, at least until recently, residential gateways provided as CPE used open source software that did not include any obvious mechanism to address automated updates to address security issues with essentially “free” (and sporadically supported) software. Because I do not believe that service providers are somehow exempt from the rule that “you gets what you pays for,” my confidence in the ability of such a provider to ensure protection of my data is – well – pretty low.
>
> [jeff] what’s your point, how is this relevant? I can’t imagine, degree of confidence being a tangible metric...
>
> And, finally, you missed my point about why a provider might choose to provide data protection via encryption. To the extent that it is effective, it is relatively cheap and easy to provide at least some level of protection using encryption.  Some types of service are unsellable to most people unless some form of data protection is provided – for example, cloud services.
>
> --
> Eric
>
> PS – by the way, if you think that “legally required” means “not optional,” you are quite possibly unaware of the more than a decade in which LI was “required” but not supported by most service providers. But that too is a different discussion. 😊
>
> PPS I have spent half of my life building large networks and business around :) there’s difference between requirements and enforcement - if said SP would have been fined $1M a week for not providing the required, they would have done it long time ago :)
>
> From: Jeff Tantsura <[e-mail]>
> Sent: Thursday, May 14, 2020 4:42 PM
> To: Eric Gray <[e-mail]>
> Cc: [e-mail]
> Subject: Re: Security, and especially encryption.
> Importance: High
>
> Eric,
>
> Users are not just asking “random stuff”, end2end encryption is a basic feature of a SSLA (secure SLA).
> This is not about user observability (user can’t observe disjoined paths or similar features either) but a capability of expressing particular logic in an NBI and ability of the provider to deliver it, there’s also no “confidence factor” it is binary, the service is either provided or it is not.
> The service (TS in our case) as defined by a provider and as consumed by a consumer is a combination (logical AND) of a set of features, all of which has to be true is order for the service fulfillment to be successful.
>
> Provider “doesn’t just want” to provide encryption as a service (it costs in OPEX and CAPEX) it is a value add service that could be delivered to a consumer as a distinct advantage ( in a competitive market) or against additional payment.
>
> Note - end2end encryption for compliance reasons (e.g PCI, HIPAA, similar) if required is not optional
>
> Cheers,
> Jeff
> On May 14, 2020, 10:42 AM -0700, Eric Gray <[e-mail]>om>, wrote:
>
> > Jeff,
> >
> > I agree that a user may ask (or, if they are big enough, insist) that a provider encrypts their data.
> >
> > However, as I said during the meeting, either a user encrypts their own data, or they have no way to determine that it is not encrypted – other than through some failure scenario where their data appears (in unencrypted form, or “plain text”) somewhere where it should not have.
> >
> > If we allow that “detection” of non-performance on some service objective may occur in any failure scenario, then we cannot immediately distinguish the case where the provider intended to meet the criteria and the mechanism used (e.g. – encryption) failed, from a case where the provider did not take any steps to meet the criteria (again, encryption of the data) and this was only discoverable as a result of some other uncommon failure (e.g. - the unencrypted data was intercepted by some third party, or was stored in unencrypted format in some location which was subsequently accessed by an unauthorized entity).
> >
> > If the data is “leaked” in unencrypted form in some extremely uncommon cases, it is not actually possible to determine if that was because it was never encrypted, or if it was only exceptionally unencrypted.
> >
> > In this sense, a user requesting encryption is essentially saying “if the service can do so, I would like my data encrypted.” That is, while I agree that we may want to include this as a parameter in the NBI (I suggest that is a bad idea), it would be unenforceable (except via legal recourse, and auditing).
> >
> > And it is not actually the best way to represent what the customer really wants.
> >
> > It is far more useful for the consumer to indicate their preference that their data is protected (in some way), with some degree of confidence (up to and including 100%) from exposure to unauthorized parties.
> >
> > As a separate, out of scope in this work, issue – legal documents (e.g. – an SLA) may explicitly stipulate remedies and recourses. IETF does not specify these
> >
> > Many providers may find it simply easier to allow customers to request their data is encrypted – especially if their network equipment includes the capability at a relatively low cost (e.g. – no perceptible impact on traffic handling). But that does not mean this is the only (or even necessarily the best) way to provide the data protection that a user requested.
> >
> > Encryption, by the way, does not (by itself) ensure that a customer’s data is completely protected (which is another reason for the customers to ask for what they really want), because – if the provider is doing the encryption and decryption themselves, there are two (or more) points at which the data exists in the provider’s network equipment in an unencrypted form.
> >
> > Note that – if a provider really wants to use encryption to meet the data protection requirement – there is actually no reason why a “higher layer” controller cannot translate a request for data protection at some (possibly variable) level of confidence into an explicit request to an NBI.
> >
> > Another reason to list this as distinct “protection” and “confidence” factors (as opposed to a simple “encrypt my data” factor) is that additional degrees of confidence are achievable. For instance, a provider might choose to deploy a more expensive device on a customer’s premises that does whatever it is that the provider chooses to use for protecting the customer’s data (e.g. – encryption) using a platform that is explicitly hardened against unauthorized access and/or hacking (possibly using more sophisticated algorithms).
> >
> > As it is, the current “Security” objective conflates multiple security aspects – of which data protection is but one.
> >
> > --
> > Eric