> > Regarding speed, the first few pages I hit made a comment that it was > slower because of packet overhead. I'm reading more and that is less of > a concern. >
There's certainly a penalty paid for the extra time encrypting and decrypting , which of course can aggregate over a large number of protected links. But unless you're trying to manage latency budgets in the microseconds range it's not likely to be an issue. On Mon, Oct 21, 2024 at 3:01 PM John Schiel <jsch...@flowtools.net> wrote: > > Thanks. > > I threw this out there not knowing how fast someone would respond. > > I only heard about this recently and am surprised it as as old as it is. > > Regarding speed, the first few pages I hit made a comment that it was > slower because of packet overhead. I'm reading more and that is less of > a concern. > > --jas > > On 10/21/24 12:28 PM, Saku Ytti wrote: > > On Mon, 21 Oct 2024 at 20:34, John Schiel <jsch...@flowtools.net> wrote: > > > >> 1) May not work over wireless LAN devices? > > I guess it depends on wireless technology, but 802.11xyzzy comes with > > an encryption solution already so isn't really a target of interest. > > > >> 2) Needs a centralized key server. > > Not really, implementation detail. > > > >> 3) May not be supportable on all devices? > > Definitely not supported on all devices, you tend to pay extra, but > > getting an increasingly small premium to pay. May become essentially > > free, depending on demand. > > > >> Purported to be faster on the LAN than IPsec because MACsec is on layer > 2. > > Speed doesn't have anything to do with layer2 or layer3, you may be > > assuming that ipsec is software and macsec is hardware which may be > > true, but is implementation detail. For example Juniper Trio can do > > some forms of IPSEC on the same hardware as MACSEC at the same > > performance profile. > > > > > > It is not exactly new technology, these devices have existed for +decade > now? > > > >
