Re: [Ace] discussion on draft-vasu-ace-core-access-privilege-provisoining-00

[Vasu Kantubukta <[e-mail]>]

Hi Ludwig Seitz,

Plz find my inline comments:

I'm still trying to clarify the details of the approach you propose,
so please excuse the barrage of questions.
--> Questions are always welcome.
--> Even, We are very happy that experts like you are interested in reading the draft and providing us some feedback/suggestions.

In figure 2 it looks like the RS has to do an online lookup at the AS to get an access control decision while in figure 3 it seems as if the AS
itself executes the request on behalf of the client.

Both cases work fine if the RS can connect to the AS at the time of the request, but if you look at RFC 7744 we have usecases where this is not
possible or not cost effective (e.g. in terms of battery usage). Have you considered such usecases?

From our discussion I got the impression that in your approach, both access control and resource control policies are provisioned to the AS
only and not to the RS, but in figure 3 is seems like the RS makes some access control decision towards the AS, I wonder based on which policies
that happens?

--> good catch. Some text is missing in the figure 3, we will update in the draft. Whenever request comes from the client device, the provisioning server (PS) provisions the request based on admission and resource control policies of RS for the client at PS. Then PS will do it onbehalf of client device (e.g. in figure 17). In both cases, PS has to contact the RS whenever request comes. As u mentioned, and as per the RFC 7744, it may not be possible or not cost effective in some usecases. In such cases, Alternative solution such as mentioned in section 7 of the draft (draft-vasu-ace-core-access-privilege-provisioning-00) can be used. Here, only PS interacts with RD.
Even in such cases, RD has similar problems, where RD may have to do the following:
1) Can use proxy feature which extends the functionality of RD. Sleepy nodes delegates its resources to proxy. (as mentioned in draft https://tools.ietf.org/pdf/draft-zotti-core-sleepy-nodes-04.pdf)

As I said, the AS can very well consider resource control or scheduling when making an access control decision, but the details of how the AS 
makes access control decisions are not in scope for ACE.

-->This query was raised long time back to Core-WG, where to address this draft, and it was suggested by Bormann to address to both Core, and ACE groups. (https://www.ietf.org/mail-archive/web/core/current/msg06057.html)
Moreover, in last 94th meeting it was presented under t2trg.
Eventhough, I could not attend the meeting due to VISA problems, My colleague presented the draft idea in 94th meeting at Japan.
(https://tools.ietf.org/html/draft-vasu-core-ace-service-provisioning-00)


Thanks and Best Regards
K Vasu




-----Original Message-----
From: Ace [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 2016年4月23日 0:30
To: [e-mail]
Subject: Ace Digest, Vol 29, Issue 18

Send Ace mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ace
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ace digest..."

--- Begin Message ---

Hello,

I'm still trying to clarify the details of the approach you propose,
so please excuse the barrage of questions.

In figure 2 it looks like the RS has to do an online lookup at the AS to
get an access control decision while in figure 3 it seems as if the AS
itself executes the request on behalf of the client.

Both cases work fine if the RS can connect to the AS at the time of the
request, but if you look at RFC 7744 we have usecases where this is not
possible or not cost effective (e.g. in terms of battery usage). Have 
you considered such usecases?

 From our discussion I got the impression that in your approach, both
access control and resource control policies are provisioned to the AS
only and not to the RS, but in figure 3 is seems like the RS makes some
access control decision towards the AS, I wonder based on which policies
that happens?

> Why would the scheduling problem be caused by the access control
> mechanism? That causality doesn't seem obvious to me, please explain
> in more detail.
> --> Here, If I am not wrong, you mentioned that same access tokens
> can be valid for multiple resources.

Right

> If access control does not consider resource availability and
> resources max capacity to handle the request. Then clients need to
> send the resource request to multiple resource servers. Then it may
> need a scheduling by a proxy.

As I said, the AS can very well consider resource control or scheduling 
when making an access control decision, but the details of how the AS 
makes access control decisions are not in scope for ACE.

I also get the feeling that you got hang up on my simplistic example of 
a client sending a request to multiple resource servers. I guess a more 
realistic example would be that there are proxies taking care of 
scheduling, independently of the access control mechanism in place. 
Alternatively you could imagine a setting where the client broadcasts or 
multicasts its request.

>
> It seems to me that your goal is to include resource control aspects
> into that decision, and that is fine by me, but not relevant for the
> ACE work, which deals with encoding the access control decision into
> a token, getting the token to the Resource Server and then having the
> RS enforce that access control decision. --> Can you suggest me,
> which group I can reach for?

I don't think there is an IETF working group on that topic.




> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ace digest..."

Please note this ^^^^^^



/Ludwig


-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone [phone]
http://www.sics.se

--- End Message ---

--- Begin Message ---

Hi Vasu,

thanks for your draft. I have browsed through it and I had a number of
questions and I wanted to start with one aspect that seems to be quite
central to your document.

In the introduction you talk about RD and the past work in the IETF CORE
working group.

Then, you introduce a Commissioner:

   Once the services are advertised by any device, those services need
   to be verified using commissioner. CORE RD provides a standard
   procedure to interact with commissioner, where commissioner acts like
   a client device to look up and verify the advertised services. Once
   the commissioner verifies the pre-registered services, commissioner
   can put some policy rules on services hosted by devices for resource
   control.

The term itself is defined in the terminology section:

      o "Commissioner" Commissioning agent is tool/device that verifies
      the devices operation, integrity check with the network.

Could you explain a little bit what you mean by "verifies the device
operation", and "integrity check with the network"?

Ciao
Hannes

PS: You may have missed a few working group meetings and therefore you
may not know that we have already made a decision regarding the solution
direction regarding the use of OAuth for IoT.

--- End Message ---