Re: ISMS working group and charter problems

Hi Steve,

> I agree that the functionality you suggest is useful.  The trick is to 
> permit that without permitting misbehavior.  (I'll note here that the 
> interests of vendors and the interests of users are not identical.  
> More and more, vendors like subscription-based models, where users keep 
> on paying, to give just one example.)  This requires not just a 
> view-based access control model -- where the view might be "MIB 
> variables for this call only" -- but an express intent by the user to 
> permit the access for that particular call.  This demands a different 
> notion of "view" than has been traditional; it also implies a user 
> interface issue and -- given the existence of firewalls -- a multi-
> party protocol:  my endpoint, your endpoint, my management proxy (which 
> is accessible through the firewall), your management proxy, and the 
> vendor's diagnostic station.  I'd be hard-pressed to see this as within 
> scope for ISMS.  It may, however, be a very nice subject for a separate 
> working group.

I think there are a few models that could be considered.  The first is
where a single administrative domain is at play, where really my
management proxy = your management proxy.  This might be an optimization
of what you're saying.  Arguably you're already talking to my management
proxy through SIP.  An alternative model that has been mentioned is a
way to query OIDs over SIP.  I'm not a SIP guy so I don't know if the
SIP proxy can even initiate queries.

In the case you mentioned, with four proxies, I'm okay with that as long
as it's not mandated in the model.  Anything that requires four of
anything is never going to survive the Internet.  e2e is hard enough
with 2 devices ;-)

> 
> 
>>Furthermore, if the phone wants to send a notification to a manager, it
>>too is likely to reside behind a firewall.
> 
> 
> Not if the site is properly managed.  The manager's port should be 
> exposed to the outside.  Just as web servers have to permit inbound 
> port 80 and mail servers have to permit inbound port 25, a management 
> station has to accept its own traffic.  A firewall can, at best, 
> protect the other ports on the machine -- but those should be turned 
> off anyway.

You can't really tell where the firewalls area going to be in the
general case.  And with mobile managed devices, you really can't tell,
because access will vary.  My point was that in the case where a
notification connection is initiated in one direction and a request
connection is initiated in another, you're all but guaranteed that one
or the other will fail in the face of a firewall, and that is the
current envisioned approach.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf