Subject: [Teep] IETF 101 agenda requests

From: Dave Thaler <[email-masked]>
Date: Fri, 16 Mar 2018 19:38:15 +0000

Please send your requests for time on the TEEP WG agenda for IETF 101 as soon as possible, to [email-masked].
Priority will be given to topics that have already had mailing discussion and are targeted for items listed in charter milestones.

Please also send slides by Sunday March 18th.

Thanks,
Dave

---

From: "faibish, sorin" <[email-masked]>
Date: Thu, 22 Mar 2018 09:26:22 +0000

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:

1.       Payment

2.       IoT to allow authorized code access

3.       Confidential cloud computing

All the above usecases are only addressing the safety of the operation/execution of code on the devices. My new usecase is addressing the outgoing data/communication between the IoT device and the cloud provider that is collecting the data from the device. As it is implemented right now there is no protocol allowing protection against malicious data packets that are sent by the device by the SW running inside the protected area that passed all the security requirements of all the security players:
Developers, chip vendor, OEM vendor and TAM that are responsible for:

-          IoT Device

-          Trusted Application

-          Rich Application author

-          TEE chip vendor

-          Device OEM

We want to focus the new usecase on IoT devices lacking rich execution environment that are mostly innocent generators of DDoS traffic that was implemented in the trusted SW or in the device HW during the design allowing backdoors for the DDoS attackers. TEE should have provisioning for preventing undesired packets to be broadcasted to the network. As these devices use inexpensive HW they have no protection against the outgoing traffic even if it is encrypted, or perhaps although it is encrypted, to prevent malicious data packets to be broadcasted.

Moreover there is also a need to protect against signaling sent to the device by attackers that controls the attack timing and duration using legitimate data packets. One way TEEP protocol can protect against this type of attacks is to use a "Security Provider" entity that will detect such attacks and send signals to the IoT device to stop the broadcast of packets using a front door specially designed for this purpose and supported by the TEEP protocol. This new actor was discussed during the last meeting in London and it was not decided to add such an entity. I would like to recommend to include such an entity and provision it in the architecture design.

This can be the entity that can judge the transmission of malicious packets that will start or be a part of a DDoS attack  triggered by an innocent legitimate SW, be it trusted and legit.

So my proposal is to include the new player Security Provider as well as provisioning TEEP to allow front door signals sent to the TEE of the IoT to allow stopping DDoS attacks.

./Sorin

From: TEEP [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Friday, March 16, 2018 3:38 PM
To: teep <[email-masked]>
Cc: [email-masked]
Subject: [Teep] IETF 101 agenda requests

Please send your requests for time on the TEEP WG agenda for IETF 101 as soon as possible, to [email-masked]<mailto:[email-masked]>.
Priority will be given to topics that have already had mailing discussion and are targeted for items listed in charter milestones.

Thanks,
Dave

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Mar 2018 07:39:25 -0500

Hi Sorin,

> 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 t…

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

---

From: "faibish, sorin" <[email-masked]>
Date: Mon, 26 Mar 2018 23:12:37 +0000

We discussed the DDoS in Singapore and we had a presentation on the DDoS:
https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-inter-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

./Sorin 

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Friday, March 23, 2018 8:39 AM
To: faibish, sorin <[email-masked]>
Cc: Dave Thaler <[email-masked]>; teep <[email-masked]>; [email-masked]
Subject: Re: [Teep] IETF 101 agenda requests

Hi Sorin,

> 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 t…

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Mar 2018 20:33:01 -0500

> 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 
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep

---

From: "Wheeler, David M" <[email-masked]>
Date: Tue, 27 Mar 2018 15:43:52 +0000

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:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Monday, March 26, 2018 6:33 PM
To: faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Teep] IETF 101 agenda requests

On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote:
> https://datatracker.ietf.org/meeting/100/materials/slides-100-saag-int
> 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

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Mar 2018 16:33:41 +0000

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 <[email-masked]> 
Sent: Tuesday, March 27, 2018 8:44 AM
To: Benjamin Kaduk <[email-masked]>; faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: RE: [Teep] IETF 101 agenda requests

Ben,

Thanks,
Dave Wheeler

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Monday, March 26, 2018 6:33 PM
To: faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Teep] IETF 101 agenda requests

On Mon, Mar 26, 2018 at 11:12:37PM +0000, faibish, sorin wrote:
> 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

-Ben

> 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
[email-masked]
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

---

From: "Wheeler, David M" <[email-masked]>
Date: Tue, 27 Mar 2018 17:37:14 +0000

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

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.

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. 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, ...

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). 

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).

Thanks,
- Dave Wheeler

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2018 9:34 AM
To: Wheeler, David M <[email-masked]>; Benjamin Kaduk <[email-masked]>; faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; [email-masked]
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.

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 <[email-masked]>
Sent: Tuesday, March 27, 2018 8:44 AM
To: Benjamin Kaduk <[email-masked]>; faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: RE: [Teep] IETF 101 agenda requests

Ben,

Thanks,
Dave Wheeler

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Monday, March 26, 2018 6:33 PM
To: faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Teep] IETF 101 agenda requests

-Ben

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Mar 2018 18:21:41 +0000

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

Excellent, thanks for doing this.

All of the above makes sense to me.

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.

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?

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

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

Cc: teep <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Dave

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

From: Wheeler, David M <[email-masked]<mailto:[email-masked]>>

To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>; faibish, sorin <[email-masked]<mailto:[email-masked]>>

Cc: teep <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Ben,

Thanks,

Dave Wheeler

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

To: faibish, sorin <[email-masked]<mailto:[email-masked]>>

Cc: teep <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

procedure...)

-Ben

> To: faibish, sorin <[email-masked]<mailto:[email-masked]>>

> Cc: Dave Thaler <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

TEEP mailing list

[email-masked]<mailto:[email-masked]>

---

From: "faibish, sorin" <[email-masked]>
Date: Tue, 27 Mar 2018 23:18:48 +0000

David,

Thank you for your detailed clarifications. I just want to address one point within:

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

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
[sf] The resources used for DDoS potential attacks are not necessarily detected as extremely different as Dave pointed in the other email yet the fact that the execution of the offending code is IMHO already a breach as the secure application was used to activate network traffic that it was trusted to be real data sent to the cloud and yet it is malicious. As Dave mentioned the amount of traffic is not very large but it is sent from many IoT devices. The problem I want to address is the trust that the "safe" application was given and due to the breach the attackers are using to generate the network packets which in my opinion is a breach of trust. There is a valid question though that Dave asks: how do we identify malicious packets not in very large amounts sent by the "trusted" application. In normal situations the application may send packets to the cloud, for example, not legitimate ones. This is the real problem of trust. 

./Sorin  

Thanks,
- Dave Wheeler

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

Dave

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

Ben,

Thanks,
Dave Wheeler

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Monday, March 26, 2018 6:33 PM
To: faibish, sorin <[email-masked]>
Cc: teep <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Teep] IETF 101 agenda requests

-Ben

---

From: "Wheeler, David M" <[email-masked]>
Date: Wed, 28 Mar 2018 00:14:23 +0000

> 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

Sent: Tuesday, March 27, 2018 11:22 AM

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

Thanks,

- Dave Wheeler

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

Dave

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

Ben,

Thanks,

Dave Wheeler

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

procedure...)

-Ben

TEEP mailing list