Hi Linda, The User Group based policy can be used in the user-group-id enabled domain. For example, the ingress NSF matches on common packet header fields, such as an n-tuple, and then maps the n-tuple to the appropriate user-group-id supplied out-of-band by the Security Controller. Then, the ingress NSF inserts the corresponding user-group-id into the packet. The user-group-id is used by NSFs to make forwarding decisions in the user-group-id supported domain. This is transparent to the users.
The details will be discussed in our capability layer draft for user group based policy. Thanks, Jianjie > -----邮件原件----- > 发件人: Linda Dunbar > 发送时间: 2016年6月15日 20:57 > 收件人: Youjianjie; [email protected] > 主题: RE: User Group based policy > > Jian Jie, > > Since the connectivity among multiple Enterprise sites are most likely to be > provided by 3rd party network operators, are your proposed "User Group > based policy" used between "Enterprise network manager or controller" and > the management system (or the controller) of the provider network? > > If yes, The Enterprise users may need the capability to inquire if the desired > policy can be supported by the provider network, does it? > > Linda > > -----Original Message----- > From: Youjianjie > Sent: Monday, June 13, 2016 9:14 PM > To: Linda Dunbar; [email protected] > Subject: 答复: User Group based policy > > Hi Linda, > > Thanks for your comments. > Our "User Group Based Policy" will use the ECA paradigm. Actually we're also > working on the User Group Based Policy for Capability Layer using the ECA > paradigm. We're going to submit this draft for the upcoming IETF meeting. > > Here is an example: > Event: one NSF receives a packet with user-group-ID (e.g. the ingress NSF > inserts the corresponding user-group ID into the packet.) > Condition: user-group-ID = **** (e.g. it represents user during office hours) > Action: Permit (e.g. user accessing R&D resources is allowed) > > Further comments are welcome! > > Thanks, > Jianjie > > > > -----邮件原件----- > > 发件人: Linda Dunbar > > 发送时间: 2016年6月14日 5:35 > > 收件人: Youjianjie; [email protected] > > 主题: RE: User Group based policy > > > > Jian Jie, > > > > Will your "User Group Based Policy" also use the "Event - Condition - > Action" > > paradigm which I2NSF WG agreed to use from the Buenos Aires meeting? > > > > If your answer is "Yes", can you add the Information model for your > > "User Group Based Policy"? > > > > For example, > > - The information (and data) model for "Event" > > - The information (and data) model for "Condition" > > - The information (and data) model for "Action". > > > > It would be helpful if you post your detailed description for each > > category above on the mailing list to get some discussion before > > asking for WG adoption. > > > > Thanks, Linda > > > > -----Original Message----- > > From: I2nsf [mailto:[email protected]] On Behalf Of Youjianjie > > Sent: Monday, June 13, 2016 3:38 AM > > To: [email protected] > > Subject: [I2nsf] User Group based policy > > > > Hi, > > > > We are working on the User-group Aware Policy Control (UAPC) > > framework, which facilitates consistent enforcement of security > > policies based on user group identity. > > https://tools.ietf.org/html/draft-you-i2nsf-user-group-based-policy-01 > > > > Use cases for UAPC: > > With the increased popularity of enterprise wireless networks and > > remote access technologies such as Virtual Private Networks (VPN), > > enterprise networks have become borderless, and employees' locations can > be anywhere. > > Enabling large-scale employee mobility across many access locations > > improves enterprise production efficiency but also introduces > > challenges related to enterprise network management and security. The > > IP address of the user can change frequently when the user is in > > motion. Consequently, IP address-based policies (such as forwarding, > > routing, QoS and security policies) may not be flexible enough to > accommodate users in motion. > > > > User-group ID represents the collective identity of a group of users, > > and is determined by a set of one or more matching criteria (e.g., > > roles, 4-, 5-, and 6-tuples, VLAN ID, etc.) that disambiguates this > > user-group entity from other entities. > > > > The UAPC framework consists of four main components: (1) Policy > > Server, (2) Authentication Server, (3) Security Controller, (4) Network > > Security > Functions. > > > > Within the UAPC framework, inter-group policy enforcement requires two > > key > > components: (1) user-group-to-user-group access policies, and (2) sets > > of NSFs that are managed by sets of policies. > > > > Some requirements are proposed in the last section. > > > > Any comments or suggestions are welcome. > > > > Thanks, > > Jianjie > > > > _______________________________________________ > > I2nsf mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
