support for multicast networkpolicy

[liu4480]

Describe the problem/challenge you have
Antrea has implemented multicasr traffic support, but currently there is no networkpolicy for multicast, all multicast packet will be passed as long as the pod enters the group. For security consideration, it is better to implement networkpolicy for multicast to allow or reject multicast packet.
This proposal is to define networkpolicy for multicast, here are the requirements:

1. block IGMP queries and reports from and towards Pods

• block IGMP queries towards pods
• block IGMP reports from pods

2. limits sources (in Pods) to send multicast traffic to specific multicast IPs

---

Describe the solution you'd like

0. changes in pipeline

IGMP -> MulticastEgress -> MulticastEgressMetric -> Multicast -> MulticastIngress -> MulticastIngressMetric -> MulticastOutput

IGMP handles with IGMP query and report
multicastEgress handles multicast egress traffic
multicastEgressMetric collects metric for multicast egress metric
multicastIngress handles multicast ingress traffic
multicastIngressMetric collects metric for multicast ingress metric

1. crd defination

since there is Ingress/Egress in ACNP, it is better to reuse the existing crd defination, and extend with a member in Rule：
protocol string
to indicate what kind of protocol it is.

2. Block IGMP query and reports from and towards Pods

It needs to be possible to define Antrea Cluster Network Policies that block IGMP queries and reports from and towards Block IGMP query to pods.

2.1 Block IGMP query

for example, to block IGMP query to pod which matches label app=app1

Ingress:
- action: Drop
  appliedTo:
  - podSelector:
    matchLabels:
      app: app1
  enableLogging: false
  from: []
  name: "1000"
  protocol: IGMP

1. Antrea-agent creates a group for 224.0.0.1 in table multicast, which is the multicast address to send group query:

cookie=0x4, duration=8609.772s table=IGMP, n_packets=70, n_bytes=965, priority=200, igmp, nw_dst=224.0.0.1 actions=group:7

2. When there is new pod created, antrea-agent will added the pod into the IGMP query group, while there is pod deleted, anra-agent removes the pod from IGMP query group
3. When there is rule to block group query, antrea-agent will block the port number for matches pod to send IGMP query to the matched pod

group_id=7,type=all,bucket=bucket_id:0,actions=load:0x1->NXM_NX_REG0[8],load:0x2->NXM_NX_REG1[],resubmit(,MulticastEgress),bucket=bucket_id:1,actions=drop

4.When the rule is deleted, antrea-agent will allow the port number to send IGMP query

group_id=7,type=all,bucket=bucket_id:0,actions=load:0x1->NXM_NX_REG0[8],load:0x2->NXM_NX_REG1[],resubmit(,MulticastEgress),bucket=bucket_id:1,actions=load:0x1->NXM_NX_REG0[8],load:0x2->NXM_NX_REG1[],resubmit(,MulticastEgress)

2.2 Block IGMP report

Egress:
- action: Drop
  appliedTo:
  - podSelector:
    matchLabels:
      app: app2
  enableLogging: false
  name:""
  protocol:
  - IGMP
     - dstMcastAddr: 225.1.2.3

Antrea should block IGMP report from specific pods to any multicast address or specific multicast address

antrea-agent add rule in table IGMP. But since ovs can not read multicast address in IGMP v2/v3, maybe blocking in antrea-agent is a solution to make the behavior same. For the IGMP report message, ovs should redirect to antrea-agent if the packet if from pod (reg0=0x2/0xf), and antrea-agent will send query to ANP to check if report from pod should be blocked.

func queryAction(podRef, multicastAddr string) (RuleAction, type.UID), types.UID is the uuid for policy.

here is the rule to send packet to antrea-agent:

cookie=0x0, duration=738.660s, table=IGMP, n_packets=12, n_bytes=552, priority=210,igmp,nw_dst=225.1.2.3,reg0=0x2/0xf,action=controller

Limit specific pod to send multicast to specific multicast Ips

Egress:
- action: Drop
  appliedTo:
  - podSelector:
    matchLabels:
      app: app2
  enableLogging: false
  To:
  - IPBlock:
    - 225.1.2.3
  name:""
  ports
    protocol: "udp"

here is the rule to drop multicast traffic from pod that matches label app=app2 to multicast address 225.1.2.3:

cookie=0x10050000000000, duration=7516.682s, table=MulticastEgress, n_packets=0, n_bytes=0, idle_age=7516, hard_age=8, priority=64180,ip,nw_src=192.168.2.17 actions=conjunction(2,1/2)
cookie=0x10050000000000, duration=7516.682s, table=MulticastEgress, n_packets=0, n_bytes=0, idle_age=7516, hard_age=8,priority=64180,ip,nw_dst=225.1.2.3 actions=conjunction(2,2/2)
//load:0x1->NXM_NX_REG4[25] means this deleted by np
cookie=0x10050000000000, duration=148.512s, table=MulticastEgress, n_packets=0, n_bytes=0, priority=64180,conj_id=2 actions=load:0x2->NXM_NX_REG3[],load:0x1->NXM_NX_REG4[25],controller,resubmit(,MulticastEgressMetric)
//MulticastIngressMetric
cookie=0x10050000000000, duration=322.933s, table=MulticastEgressMetric, n_packets=0, n_bytes=0, priority=200,reg0=0x1000/0x1000,reg3=0x2 actions=drop

---

Anything else you would like to add?
thing need to be discussed is that do we need to define ingress that pod (label app=app1) does not receive multicast traffic from specific IP address (for example 192.168.1.100) to multicast address 225.1.2.3?
If yes, we need to introduce a new member to store the multicast address. something like:

Ingress:
- action: Drop
  appliedTo:
  - podSelector:
    matchLabels:
      app: app1
  enableLogging: false
  from: 
  - IPBlock:
     - 192.168.1.100
  name: "1000"
  protocol: "udp"
 to:
 - IPBlock:
     - 225.1.2.3

I think we can put ingress for multicast traffic in low priority

[wenyingd]

I have a question about how to represent an Ingress rule for multicast traffic? What should be the "appliedTo" value, multicast address or Pods? If it is multicast address, the existing ANP API doesn't support using IPBlock as AppliedTo field, and AntreaController might not able to calculate the ANP span. If the appliedTo is a Pod, how would you identify this is a rule for multicast but not for a general unicast traffic?

[wenyingd]

From my understanding, Antrea should support 3 scenarios for multicast: 1) Pods only work as multicast sender, 2) Pods only work as multicast receiver, 3) Pods work as both multicast sender and receiver. If we only support Egress rule with multicast, I don't think we can satisfy the security requirement for senario 2.

[liu4480]

I have a question about how to represent an Ingress rule for multicast traffic? What should be the "appliedTo" value, multicast address or Pods? If it is multicast address, the existing ANP API doesn't support using IPBlock as AppliedTo field, and AntreaController might not able to calculate the ANP span. If the appliedTo is a Pod, how would you identify this is a rule for multicast but not for a general unicast traffic?

I 'd like to introduce a field IPBlock to indicate the multicast address or other IP address. And for "appliedTo" we should use the existing implementation, for example, pod selector, clustergroup and so on.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days

[liu4480]

close as #3660 is merged