Re: IEEE MACsec

[Crist Clark <cjc+nanog () pumpky net>]

It is definitely deployed out there. I wouldn't worry too much about
reading the specs. All of the implementations I've dealt with are only
partial implementations. They almost all are limited to "point to point"
functionality.

As for comparing to IPsec, IPsec came out of a different time. It is more
of framework with a zillion knobs, and lots of room for customization and
future changes. The keying isn't even a part of IPsec. ISAKMP, later IKE,
are separate protocols. IPsec has transport mode (seldom used) and tunnel
mode. It has AH (which no one uses) and ESP.

MACsec is much more narrowly defined. The cryptographic algorithms are
standard. There is room for future updates of those algorithms, but for
now, the implementers know what they need to do.

For those reasons, I think it is more straightforward to implement MACsec
in firmware. I would expect if you trimmed down IPsec, which most NOS
implementations already do, you can implement it in the same way.

Vendors have been charging big money for fast IPsec for a long time, they
don't want to stop. But the MACsec price-point is so sweet compared to it,
you now have people doing things like running MACsec over VXLAN in place of
IPsec.


On Mon, Oct 21, 2024 at 1:32 PM Tom Beecher <beecher () beecher cc> wrote:

> 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 <jschiel () 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 <jschiel () 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?
> > >