[Cryptography] Low grade randomness for padding.
billstewart at pobox.com
Sat Feb 13 13:52:49 EST 2021
On 2/10/2021 3:50 PM, John-Mark Gurney wrote:
> Phillip Hallam-Baker wrote this message on Wed, Feb 10, 2021 at 11:40 -0500:
>> On Wed, Feb 10, 2021 at 11:13 AM Kent Borg <kentborg at borg.org> wrote:
>> This has got me back to an old gripe I have about the idiocy of Ethernet
>> jumbo frames being limited to 9000 bytes which really isn't much of an
>> improvement. The justification for the stupidity is that CRC checksums
>> don't work on longer packets. Which is of course a stupid argument when we
>> are talking about a network predicated on the end-to-end principle.
My comment a couple of decades ago was that I don't need 9000-byte jumbo
frames very often, but it sure would be nice to have 2000-byte frames so
that my 1500-byte TCP packets can have a couple layers of VPNs or
whatever wrapped around them.
But that intuition _is_ left over from the days that 1.5 Mbps
connections were common, so a 1500-byte packet throws in 8ms of jitter,
and a 9KB throws ~50ms, and that's enough to start to be annoying,
especially if you've got VOIP around.
64KB on a 10Mbps cable modem is still ~50ms.
>> What I would do to fix this is to
>> 1) Strip out all legacy support at the link layer for non-IP protocols.
>> Ethernet MAC addresses serve no function, kill them. WiFi etc. need
>> identifiers but they don't need to be visible above the WiFi layer. Use IP
>> to route on the LAN, it is what it is for.
> To be compatible w/ existing networks, you could just move the IP
> addresses into the MAC address field, allowing modern hardware to still
> work (assuming it allows the MAC address filter to be changed).
Switching needs to be dumb so it can be fast and cheap, and high-volume
stuff works better that way than with routing. IPv6 does have enough
address space you could do something like that (IPv4 doesn't, unless
you're using RFC1918 everywhere internally and then doing NAT out to the
real world.) At some point you end up reinventing frame relay otherwise.
>> 2) Introduce a Jumbo packet with a maximum size limited only by the IP
>> packet size of 64KB minus a few hundred bytes to allow the link layer room
>> to work within packets described by a 16 bit length.
>> 3) Limit the link layer checksum to the first 128 bytes of the packet. This
>> helps prevent errors causing packets to be mis-routed which is a link layer
>> 4) Make integrity of the payload purely the concern of the transport and
>> presentation layers. Once we decide that packets are going to be encrypted
>> using AEAD, we have no need for link layer integrity checks on the payload.
>> Just get rid of them.
More information about the cryptography