> > Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' > high level protocol, perhaps in much the same way as DHCP 'option' handling?
The SFF Committee specifies GBIC registers. They’d be the appropriate group to add registers for features such as MACsec, Ethernet OAM and the like. I’d also encourage a common SFF Committee feature to query and update GBIC firmware and encourage SFP vendors to make firmware freely redistributable so that SFPs can be updated by the operating system as needed to avoid security exposures (and such a feature is problematic, as it would have to be written in such a way as to prevent it being used as another mechanism resellers can use to ‘lock’ SFP sales to their equipment sales). The Committee have already specified registers for tuneable SFPs. After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. You should not be able to set the MACsec key from the optical side. That feature is not only cryptographically dubious but it also requires that the 'forwarding plane' (which might otherwise be entirely hardware) be connected to the SFP’s management plane. That’s not desirable from a design or security point of view. Note carefully that I’m not discouraging a self-keying mode where GBICs don’t verify their partners but are proof against receive-only optical taps (and in that case I’d encourage the SFF Committee to specify that implementations print their fingerprint and the fingerprint of the partner GBIC, so that people can verify after the fact that the partner expected is the one encountered). -- Glen Turner <http://www.gdt.id.au/~gdt/>
