Difference between revisions of "Honeycomb/IETF-ACL model"
(→Translation to VPP's binary api) |
(→Operational state) |
||
| Line 34: | Line 34: | ||
To check how ietf-acl model was translated to classify tables/session, low-level vpp-classfier model can be used. | To check how ietf-acl model was translated to classify tables/session, low-level vpp-classfier model can be used. | ||
| − | == Limitations | + | == Limitations == |
* egress rules are currently ignored (HONEYCOMB-234) | * egress rules are currently ignored (HONEYCOMB-234) | ||
| Line 45: | Line 45: | ||
| − | == VPP classier limitations | + | == VPP classier limitations == |
- lack of api for egress ACLs (could be mirror of input_acl_set_interface + classify_table_by_interface_reply) | - lack of api for egress ACLs (could be mirror of input_acl_set_interface + classify_table_by_interface_reply) | ||
- L2 rules on L3 interfaces are limited (L2 table is applied in L2 path only, IP4/IP6 table only in IP4/IP6 forwarding path). | - L2 rules on L3 interfaces are limited (L2 table is applied in L2 path only, IP4/IP6 table only in IP4/IP6 forwarding path). | ||
- no support for number ranges (would be nice to have for ports - but we need to combine it with all other rules) | - no support for number ranges (would be nice to have for ports - but we need to combine it with all other rules) | ||
Revision as of 08:21, 6 October 2016
Contents
IETF-ACL model
Honeycomb provides VPP implementation of IETF-ACL model draft 08 with following augmentations:
- possibility to assign ACLs to interfaces and sub-interfaces as ingress/egerss ACLs
- L2 + L3/L4 rules in one ACE HONEYCOMB-233
- default action for list of ACEs (removes ambiguity when mixing deny/permit rules in one ACL, HONEYCOMB-246)
Translation to VPP's binary api
Honeycomb uses classifier API to for ingress ACLs. Each ACE is translated to single classify table + session(s). We plan to minimize number of classify tables HONEYCOMB-247.
Here is short description how HC translates ACEs to classify tables and sessions. Details can be found in Honeycomb's documentation.
Configuration data
Configuration data for the model is stored in Honeycomb. Corresponding classify tables and sessions are not created until control access list is assigned to an interface.
Classify tables and sessions are removed from VPP when ACL assignment is deleted.
ACLs can be shared among interfaces, but each time, new instance of classify table chain would be created in VPP.
ACLs that are assigned to an interface have to be unassigned before update/removal.
Operational state
Operational read in terms of ietf-acl model is not supported (would require storing additional metadata in vpp). As a consequence, configuration data initialization based on operational state is not possible.
To check how ietf-acl model was translated to classify tables/session, low-level vpp-classfier model can be used.
Limitations
- egress rules are currently ignored (HONEYCOMB-234)
- ACLs could not work correctly if extension headers or ip4 options are present
- L4 rules are currently not supported
- limited support (each port in range mapped to one session) will by provided by https://jira.fd.io/browse/HONEYCOMB-218 HONEYCOMB-218])
- mixing L2/L3/L4 rules is currently not supported
- limited support will by provided by HONEYCOMB-233 (L2 rules on L3 interfaces are possible only for IP traffic)
- vlan tags are supported only for sub-interfaces defined as exact-match
VPP classier limitations
- lack of api for egress ACLs (could be mirror of input_acl_set_interface + classify_table_by_interface_reply) - L2 rules on L3 interfaces are limited (L2 table is applied in L2 path only, IP4/IP6 table only in IP4/IP6 forwarding path). - no support for number ranges (would be nice to have for ports - but we need to combine it with all other rules)
