Messages in this thread | | | Date | Wed, 21 Aug 2019 11:27:27 +0200 | From | "" <> | Subject | Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure |
| |
The 08/21/2019 09:20, Igor Russkikh wrote: > > Talking about packet numbers, can you describe how PN exhaustion is > > handled? I couldn't find much about packet numbers at all in the > > driver patches (I hope the hw doesn't wrap around from 2^32-1 to 0 on > > the same SA). At some point userspace needs to know that we're > > getting close to 2^32 and that it's time to re-key. Since the whole > > TX path of the software implementation is bypassed, it looks like the > > PN (as far as drivers/net/macsec.c is concerned) never increases, so > > userspace can't know when to negotiate a new SA. > > I think there should be driver specific implementation of this functionality. > As an example, our macsec HW issues an interrupt towards the host to indicate > PN threshold has reached and it's time for userspace to change the keys. > > In contrast, current SW macsec implementation just stops this SA/secy. > > > I don't see how this implementation handles non-macsec traffic (on TX, > > that would be packets sent directly through the real interface, for > > example by wpa_supplicant - on RX, incoming MKA traffic for > > wpa_supplicant). Unless I missed something, incoming MKA traffic will > > end up on the macsec interface as well as the lower interface (not > > entirely critical, as long as wpa_supplicant can grab it on the lower > > device, but not consistent with the software implementation). How does > > the driver distinguish traffic that should pass through unmodified > > from traffic that the HW needs to encapsulate and encrypt? > > I can comment on our HW engine - where it has special bypass rules > for configured ethertypes. This way macsec engine skips encryption on TX and > passes in RX unencrypted for the selected control packets. In our case it is a TCAM which can look at various fields (including ethertype), but is sounds like we have a vary similar design.
> But thats true, realdev driver is hard to distinguish encrypted/unencrypted > packets. In case realdev should make a decision where to put RX packet, > it only may do some heuristic (since after macsec decription all the > macsec related info is dropped. Thats true at least for our HW implementation). Same for ours.
> > If you look at IPsec offloading, the networking stack builds up the > > ESP header, and passes the unencrypted data down to the driver. I'm > > wondering if the same would be possible with MACsec offloading: the > > macsec virtual interface adds the header (and maybe a dummy ICV), and > > then the HW does the encryption. In case of HW that needs to add the > > sectag itself, the driver would first strip the headers that the stack > > created. On receive, the driver would recreate a sectag and the macsec > > interface would just skip all verification (decrypt, PN). > > I don't think this way is good, as driver have to do per packet header mangling. > That'll harm linerate performance heavily. Agree, and it will also prevent MACsec offload in offloaded bridge devices.
/Allan
| |