Difference between revisions of "VPP/SecurityGroups"

From fd.io
< VPP
Jump to: navigation, search
(API)
(API)
Line 88: Line 88:
 
         u16 dst_min_port;
 
         u16 dst_min_port;
 
         u16 dst_max_port;
 
         u16 dst_max_port;
  }
+
  };
 
    
 
    
 
      
 
      
Line 95: Line 95:
 
         u32 context;
 
         u32 context;
 
         i32 retval;
 
         i32 retval;
  }
+
  };
 
    
 
    
 
    
 
    
Line 118: Line 118:
 
         u16 dst_min_port;
 
         u16 dst_min_port;
 
         u16 dst_max_port;
 
         u16 dst_max_port;
  }
+
  };
 
    
 
    
 
      
 
      
Line 125: Line 125:
 
         u32 context;
 
         u32 context;
 
         i32 retval;
 
         i32 retval;
  }
+
  };
 
    
 
    
 
    
 
    
Line 148: Line 148:
 
         u8 mac_address[6];
 
         u8 mac_address[6];
 
         u8 ip_address[16];
 
         u8 ip_address[16];
  }
+
  };
 
    
 
    
 
  /**  
 
  /**  
Line 159: Line 159:
 
         u32 context;
 
         u32 context;
 
         i32 retval;
 
         i32 retval;
  }
+
  };
  
 
== CLI ==
 
== CLI ==

Revision as of 14:00, 12 October 2016

VPP Security Groups

Introduction

Features are tracked as they are developed in the following VPP-427.

Requirements

  • Support classifiers/filters on any interface type (bridged / routed)
  • Filter on IP-addresses with address mask or prefix length (IPv4 and IPv6)
  • Filter on source and destination TCP/UDP port ranges
  • Filter on source and destination L2 MAC addresses
  • Support IPv6 with extension headers present
  • Support fragmented packets and unknown transport layer headers
  • Combinations of the above filters (e.g. MAC + IP)
  • Filters on ingress and egress interfaces
  • Stateful firewall. No application layer filtering.

Work list

Task Owner Priority Status Description
API definition Ole 0 WIP
Ingress/Egress support for classifier 0
Support for L2/L3 interfaces 0
"Established" behaviour 1
Stateful firewall 1
Port ip_tables_firewall.py from Neutron as unit test 1

API

There is no API to set the default policy - this behavior can be achieved by adding a wildcard (all zero) protocol/ports/address, and may be handled internally as a special case. Nonetheless, there is no explicit API for setting this. Between the overlapping rules with different actions, the more specific rules always match first. This is done to ensure the matching is order-independent, as well as to allow the flexibility in the internal implementation.

/**
  Add or delete egress IP access policy rule. 
  The egress rule (*to* host(s) attached to this particular interface) 
  allows/denies the sessions to be initiated *to* the services running on this host(s).   
  */
 
define ip_apr_add_del_egress
{
       u32 client_index;
       u32 context;
       u32 sw_if_index;
       u8 is_add
       u8 allow;
       u8 is_ipv6;
       u8 src_ip_addr[16];
       u8 src_ip_prefix_len;
       u8 proto;
       u16 dst_min_port;
       u16 dst_max_port;
};
  
   
define ip_apr_add_del_egress_reply
{
       u32 context;
       i32 retval;
};
  
  
  
/**
  Add or delete ingress IP access policy rule. The ingress rule (*from* host(s) attached 
  to this particular interface) allows/denies the sessions to be initiated 
  *from* the host(s) attached to this interface.   
 */
  
define ip_apr_add_del_ingress
{
       u32 client_index;
       u32 context;
       u32 sw_if_index;
       u8 is_add;
       u8 allow;
       u8 is_ipv6;
       u8 dst_ip_addr[16];
       u8 dst_ip_prefix_len;
       u8 proto;
       u16 dst_min_port;
       u16 dst_max_port;
};
  
   
define ip_apr_add_del_ingress_reply
{
       u32 context;
       i32 retval;
};
  
  
/**
  Add or delete MAC / IP ingress filter. 
  These rules restrict the MAC addresses that can send the traffic. 
  If the ip_address is all-zero, any IP address is allowed and only
  the MAC address is used for the ingress filtering.
  There can be many MAC addresses on a given interface,
  a given MAC address may have multiple addresses associated with it 
  (by means of separate ingress rules), and different MAC addresses can also have the same addresses.  
*/
  
  
define ip_apr_macip_add_del_ingress
{
       u32 client_index;
       u32 context;
       u32 sw_if_index;
       u8 is_add;
       u8 is_ipv6;
       u8 mac_address[6];
       u8 ip_address[16];
};
  
/** 
  @param context            - sender context, to match reply w/response
  @param retval             - return code for the request
*/
  
define ip_apr_macip_add_del_ingress_reply
{
       u32 context;
       i32 retval;
};

CLI

set interface input acl intfc <int> [ip4-table <index>] [ip6-table <index>] [l2-table <index>] [del] 
show inacl type [ip4|ip6|l2]
classify table [miss-next|l2-miss_next|acl-miss-next <next_index>] mask <mask-value> buckets <nn> [skip <n>] [match <n>] [del]
show classify tables [index <nn>]
classify session [hit-next|l2-hit-next|acl-hit-next <next_index>|policer-hit-next <policer_name>] table-index <nn> match [hex] [l2] [l3 ip4] [opaque-index <index>]
test classify [src <ip>] [sessions <nn>] [buckets <nn>] [table <nn>] [del]
set ip classify intfc <int> table-index <index>
set interface ip6 table <intfc> <table-id>
set interface l2 input classify intfc <interface-name> [ip4-table <n>] [ip6-table <n>] [other-table <n>]
set interface l2 output classify intfc <<interface-name>> [ip4-table <n>] [ip6-table <n>] [other-table <n>]
set ip source-and-port-range-check
show ip source-and-port-range-check vrf <nn> <ip-addr> <port>

Examples

YANG model

Open Issues

  • Security Group use case specific API. Done in VPP or control plane plugin?

References