DHCP packets can be trapped to ONOS without Authentication

From Marcelo Souza

Related how the DHCP packets are trapped to VOLTHA from BAL:
We can see, ethertype filtering on ONU side neither using BAL 3.1
-on BAL 3.1: the packets were trapped to host CPU (VOLTHA) using flows and applied to ONUS or allocIDs. This allowed the trapped of packets to the right subscribers
-on BAL 3.4: we are trapping packets to host CPU by ACl and it is applied to PON ports. It means all users of a PON port can have their packets trapped to HOST CPU does not matter if they are authenticated or not. I.E: Case one subscriber has been authenticated an ACL to trap DHCP packets is installed on DNX, however subscribers that  has not been authenticated can have their packets  also forwarded to ONOS and BNG ( letting an open path for DDoS)Looking on openomci and g988 specs, case we use extended vlan ME171 to filter ethertype equal to 5 (0x888E/EAPOL), we could avoid such behavior, but it seems the adapter is not using such ethertype filtering capacity since it is leaving this field hardcoded as 0 (Do not filter on Ethertype). Is there any reason for that?

From Girish Gowdra

I agree with you that such an optimization could work where we filter on the EAPOL etherType only with the EVTO ME config you mentioned. BAL version prior to 3.4 version did not have ACLs and worked with flows to trap the packets. So we had a protection at OLT to avoid trapping unwanted packets to ONOS. But ACLs replacing trap-to-host flows in BAL3.4 and beyond we could have unexpected consequences as you mention. With the protection removed in OLT, we can have the protection in ONU per your suggestion. Would you like to submit a patch in the openonu adapter to fix this? Note that when the subscriber configuration is pushed (I mean the subscriber tags), such filter on EAPOL etherType only should be removed. It will remain only until initial auth is complete. Also to consider the fact is not all operator workflows might need EAPoL, so we need to push such a config only on EAPoL flow at adapter.

From Chip Boling

for the trap issue you mention with ACLs in BAL 3.4, it seems fixing a BroadCom API limitation (assuming it cannot do this on a per-gem basis) with a workaround in the ONU device adapter flows seems to be wading into dangerous areas.   In VOLTHA, the exception packets/ACLs were primarily the domain of the OLT device adapter primarily to keep the ONU device adapter simple.  Also keeping the flows simple on the ONUs helps insure a greater chance a set of default flow setup tasks work across multiple ONU vendors.Adding this workaround to the ONU device adapter (whether in GO or Python) may result in quite a bit of regression testing needed for ONUs as they come on board.   Is there no way this could be kept in the OLT?     For Tibit OLT, we are not Bcrm based and can do per-GEM ACLs so the workaround really has no impact, I'm just more worried about complexity in any ONU device adapter.  OMCI stacks interoperability is always a pain in PON unfortunately.