Re: [Teep] IETF 101 agenda requests

["Wheeler, David M" <[e-mail]>]

> Now you lost me.  To conduct a DDoS attack against an external entity you don't have to process packets very fast at all.

> You, and zillions of other devices like you, sending packets at a slow rate, collectively add up to a DDoS attack against a victim.

> Sorin's original use case, as I understand it, is about devices being able to conduct DDoS attacks.

I see. I wasn't in the presentation, I just briefly looked over the slides. What I saw in Sorin's use case was not CONDUCTING DDoS attacks, but about STOPPING DDoS attacks, by implementing a filter on a device, preventing certain types of traffic from exiting the device. See slide 9, where the Admin and some external trusted party activate policies inside the TEE where a TEE app is classifying and rate limiting outbound traffic.

This slide 9 implies access to the packet stream, which may require special privileges.

Perhaps I misunderstand Sorin's proposal? Perhaps this is a different use case?
Thanks,

-        Dave Wheeler

From: Dave Thaler [mailto:[e-mail]]
Sent: Tuesday, March 27, 2018 11:22 AM
To: Wheeler, David M <[e-mail]>; Benjamin Kaduk <[e-mail]>; faibish, sorin <[e-mail]>
Cc: teep <[e-mail]>; [e-mail]
Subject: RE: [Teep] IETF 101 agenda requests






-----Original Message-----
From: Wheeler, David M <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, March 27, 2018 10:37 AM
To: Dave Thaler <[e-mail]<mailto:[e-mail]>>; Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>; faibish, sorin <[e-mail]<mailto:[e-mail]>>
Cc: teep <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Teep] IETF 101 agenda requests



> For it to not be orthogonal, one would have to argue how/why it affects the OTrP protocol itself.



OK, let me try to present the argument :)



Excellent, thanks for doing this.



A TEE application, when provisioned into a device, will require certain resources of the device.

These resources will definitely include storage, RAM, and possibly some measure of CPU time.

OTrP //should// have some policy hooks that allow a device/device user/owner to define what are acceptable limits of resource consumption for a TEE application. For example, as long as a TEE app consumes less than 100MB RAM, it is OK to install (perhaps because I only have 250MB allocated to the TEE, and I don't want ALL the memory consumed by one app).



This policy should be attached to the TEE application at install time, be interpreted by the OTrP Agent, and be evaluated as an intersection of the application characteristics along with the device/platform/TEE policy.



Now, once these simple TEE app characteristics (memory, storage, CPU time) are considered, there are other characteristics that a TEE app might want/need access to. Here are some examples:

- device monotonic counter: some platforms have limits as to how often the MC can be updated, and the entire life of the MC, based on flash wear leveling. Restricting how a TEE app can use a MC is a policy decision for the device/TEE



- secure key store: there may be limits to the number of keys that can be stored within the TEE in a replay protected non-volatile secure storage area. Access to this might be based on a TEE policy



- other trusted HW devices: some devices on the platform may solely be accessible inside the TEE, others might be configurable to be in the TEE or outside. And access to these devices might need to be restricted. For example, access to certain FW flash areas for secure update, access to the Safety Island on certain industrial parts, and of course access to the network, especially in a promiscuous mode.



Additionally, I might configure my device so that //certain// service providers are trusted to a level where they get access to //all// these types of special resources (I trust those service providers) and other service providers do not get any such access, or very limited access. One might argue, how can you enforce this? The TEE manifest that includes the characteristics and requirements could lie - yes, but then they would be found out, because their app is signed, and they would be banned by the TSM.



All of the above makes sense to me.



So, now back to our proposed use case:

For the DDoS application to work, it must be able to get access to the lowest packet level of the network stack, and be able to process packets at line speed.



Now you lost me.  To conduct a DDoS attack against an external entity you don't have to process packets very fast at all.  You, and zillions of other devices like you, sending packets at a slow rate, collectively add up to a DDoS attack against a victim.



This requirement has significant draws on the capability of the TEE - available access to the network device, amount of memory consumed for packet buffers, amount of processing to keep up with packets, ...



Sorin's original use case, as I understand it, is about devices being able to conduct DDoS attacks.  Preventing TEE apps from doing so doesn't address that use case, if REE apps on the same devices can still do the attacks, especially since that's how such attacks already work.



Some TEEs may not even be //able// to provide such services. Other TEEs may restrict it.



OTrP should be able to convey, during install, the rich set of application requirements the TEE app needs to properly run, and this should be able to be interpreted against the policy and capabilities of the TEE as interpreted by the OTrP agent (or equivalent manager in the TEE).



Again, I don't see this as addressing the DDoS use case.   I sounds like you're hinting at a separate use case which isn't about DDoS at all, maybe you can expand on that?



For this reason, I like this use case, because it represents a non-trivial application (not just an App computing pi), with interesting and complex requirements on the HW, environment, and other policy (like privacy - do I want an app that sees ALL of my network traffic and possibly be able to evaluate my network flows?)



How should OTrP handle the communication of TEE Application requirements? What policy language is built into the protocol? Does the policy language include some privacy atoms, as well as TEE resource atoms? What other characteristics can be / should be represented by the policy language? What are the limits of policy interpretation by the OTrP agent? These, I believe are valuable questions to consider. Perhaps we get to the point that it is too complex for our first version, but I would like us to have the conversation and consider it. And then, at least, have some insight to where such a descriptive policy language might intersect with the protocol (at some point).



Your last paragraph does sound potentially relevant and useful to discuss (though again, not connected to any DDoS use case in any way I can see yet).



Thanks,

- Dave Wheeler



-----Original Message-----

From: Dave Thaler [mailto:[e-mail]]

Sent: Tuesday, March 27, 2018 9:34 AM

To: Wheeler, David M <[e-mail]<mailto:[e-mail]>>; Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>; faibish, sorin <[e-mail]<mailto:[e-mail]>>

Cc: teep <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Subject: RE: [Teep] IETF 101 agenda requests



On slide 6 of the "Problem Statement" slides there were three use cases for Trusted Applications (as opposed to use cases for OTrP or TEEP per se), of which one was IoT.



The Mirai botnet attack used the REE (not a TEE) of devices to conduct attacks against an external entity.  Since TEEP is about TEE provisioning, not REE provisioning, TEEP is not directly applicable to controlling how/whether malware can be installed in the REE.



I think what David's saying is that a provisioned TEE application could have functionality to detect/mitigate something malicious that it detects an REE app is doing.  That's true, just like the TEE application could do anything else (compute pi, etc.) but we shouldn't try to enumerate every operation that a TEE application might try to do, just things that introduce requirements on OTrP.



In the "TEEP Use Cases" slides for IETF 101, these are use cases for OTrP (as opposed to use cases for Trusted Apps in general).

In the discussion around slide 6, we agreed that Rich Apps are largely orthogonal because they don't introduce

new requirements on the OTrP protocol.   I think Ben's saying this is similarly orthogonal.



For it to not be orthogonal, one would have to argue how/why it affects the OTrP protocol itself.  If there is such an argument, that would be a good way to continue this discussion.  If not, or if we don't know if there is, then it's orthogonal until such an argument is provided.



Dave



-----Original Message-----

From: Wheeler, David M <[e-mail]<mailto:[e-mail]>>

Sent: Tuesday, March 27, 2018 8:44 AM

To: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>; faibish, sorin <[e-mail]<mailto:[e-mail]>>

Cc: teep <[e-mail]<mailto:[e-mail]>>; Dave Thaler <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Subject: RE: [Teep] IETF 101 agenda requests



Ben,

I agree with you regarding the question of charter, however, I think (please correct if I misunderstand) what Sorin is proposing is to use the DDoS example as a use case to evaluate if OTrP has considered the appropriate relationships and entities within the protocol that would allow the proposed DDoS solution to be implemented.



Our charter does state that "the solution approach must take a wide range of TEE and relevant technologies" and the architecture document includes "relevant use cases." Since the DDoS proposal includes an implementation where a TEE application implements a set of filtering policies, I believe it is relevant.



I think it is a very interesting use case, since it expands beyond a simple Device-User to Service-Provider situation, and creates a more complex interaction for the application - especially the interaction of the trusted application to aspects of the device itself (i.e. filtering outgoing packets). Is our policy for accepting TEE applications rich enough (or at least extensible enough) to enable a device/user to implement controls on what applications are allowed to do, perhaps even based on the service provider installing those applications.



I believe it is in our best interest to evaluate it, and the implications of such TEE applications. We can still come to the conclusion that some aspects of supporting such a use case may be out-of-scope, but it will give us concrete information to point to regarding what is exactly out-of-scope, why it breeches our scope, and perhaps direct future additions/expansions to the protocol.



Thanks,

Dave Wheeler





-----Original Message-----

From: TEEP [mailto:[e-mail]] On Behalf Of Benjamin Kaduk

Sent: Monday, March 26, 2018 6:33 PM

To: faibish, sorin <[e-mail]<mailto:[e-mail]>>

Cc: teep <[e-mail]<mailto:[e-mail]>>; Dave Thaler <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Subject: Re: [Teep] IETF 101 agenda requests



On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote:

> We discussed the DDoS in Singapore and we had a presentation on the DDoS:

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat

> racker.ietf.org%2Fmeeting%2F100%2Fmaterials%2Fslides-100-saag-int&data

> =02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2%

> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=

> 32qt5mT4aXYjJ9gZW%2BFRegXm4GbM%2FWlOpwh6XmnJ84I%3D&reserved=0

> er-domain-ddos-mitigations-potentials-challenges-and-solutions-min-suk

> -kang/

>

> So, I would like to include this usecase as a target for the WG. I

> will write a draft related to this usecase. Thanks



Wanting it to be a target and writing a draft are both orthogonal to the question of whether the work is in-charter.  (Rechartering to include it would of course be possible, through the normal

procedure...)



-Ben



> ../Sorin

>

> -----Original Message-----

> From: Benjamin Kaduk [mailto:[e-mail]]

> Sent: Friday, March 23, 2018 8:39 AM

> To: faibish, sorin <[e-mail]<mailto:[e-mail]>>

> Cc: Dave Thaler <[e-mail]<mailto:[e-mail]>>; teep <[e-mail]<mailto:[e-mail]>>;

> [e-mail]<mailto:[e-mail]>

> Subject: Re: [Teep] IETF 101 agenda requests

>

> Hi Sorin,

>

> On Thu, Mar 22, 2018 at 09:26:22AM +0000, faibish, sorin wrote:

> > New proposed usecase for TEEP WG.

> >

> > Most recently the frequency and intensity of DDoS attacks from IoT devices increased with attacks almost every day. The reason of the proliferation of DDoS attacks from IoT devices is a result of the lower and maybe inexistent security protection of cheap IoT devices that have no security features implemented as this would increase the cost of such devices using any security HW. In the current charter of TEEP there sre 3 usecases and I would like to add the protectioin against DDoS of IoT as a new usecase:

>

> On a quick read of the charter, I don't see how this topic would be in scope -- am I missing something that would allow it?

>

> Thanks,

>

> Ben

>

> _______________________________________________

> TEEP mailing list

> [e-mail]<mailto:[e-mail]>

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i

> etf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft

> .com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011

> db47%7C1%7C0%7C636577622384270342&sdata=1F4dZBFAumiRdEl7G4FYn0bO9VSzFy

> k%2BSkxW6cCfesw%3D&reserved=0



_______________________________________________

TEEP mailing list

[e-mail]<mailto:[e-mail]>

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cdthaler%40microsoft.com%7C105f96f6b0744e2a276408d593f98cc2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636577622384270342&sdata=1F4dZBFAumiRdEl7G4FYn0bO9VSzFyk%2BSkxW6cCfesw%3D&reserved=0