Honeycomb/IETF-ACL model

From fd.io
< Honeycomb
Revision as of 08:09, 6 October 2016 by Mgradzki (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

IETF-ACL model

Honeycomb provides VPP implementation of IETF-ACL model draft 08 with following augmentation:

  • 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 minimise number of classfy sessions HONEYCOMB-247

==== 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
  • 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)

Retrieved from "https://wiki.fd.io/index.php?title=Honeycomb/IETF-ACL_model&oldid=3424"