Hi Jianjie, Now that I understand better the idea (and I must say I see a clear value in it) I still have a couple of procedural doubts:
1) Will you align your capability layer draft with the proposal on the capability layer recently made by Sue for a packet filtering system? I’d definitely encourage you to do so 2) This is more for the chairs than for you: What are we going to do as a group with all the potential capability layer extensions that could follow the same path as this proposal? Be goode, On 16 Jun 2016, at 11:11 , Youjianjie <[email protected]<mailto:[email protected]>> wrote: Hi Linda, Yes, there're other actions such as traffic-rate, marking, etc besides permit or deny. The following is an example. This draft https://tools.ietf.org/html/draft-you-i2nsf-user-group-based-policy-01 focuses on the requirements at the service layer. The details will be discussed in our capability layer draft. Thanks, Jianjie -----邮件原件----- 发件人: Linda Dunbar 发送时间: 2016年6月15日 20:58 收件人: Youjianjie; [email protected]<mailto:[email protected]> 主题: RE: User Group based policy Jian Jie, Besides "permit" or "deny" for the enterprise customers, do you see the following actions that might be desired by the Enterprise customers? Some nodes of the enterprise network may need to request some traffic to be traversing IPsec channel, but the node themselves may not support the IPsec feature. So that Enterprise controller may inquire if the needed IPsec resource are even available from the provider network and then send the request (may involve AAA process between controllers of Enterprise and Provider domains ). Linda -----Original Message----- From: Youjianjie Sent: Monday, June 13, 2016 9:14 PM To: Linda Dunbar; [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
