<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 11:13 AM Kent Borg <<a href="mailto:kentborg@borg.org">kentborg@borg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 2/9/21 12:40 PM, Phillip
Hallam-Baker wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div style="font-size:small">So, the last
thing I need to write for the Mesh is a presentation layer.
This has the primary function of providing authentication over
HTTP and encryption and authentication over UDP.<br>
</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">The UDP
packet format is intentionally as opaque as possible, there
are two basic types of packet</div>
</div>
</blockquote>
<p><br>
</p>
<p>The responses all seem concerned with padding being a covert
channel risk.<br>
</p>
<p>Another concern is leaking data through message length.
(Encrypted voice can frequently understood just on data sizes over
time.) Padding with random data fights that</p></div></blockquote><div><div class="gmail_default" style="font-size:small">And packet timing...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As with QUIC, I am using fixed sized packets (1200 bytes), precisely to conceal the message length.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The more packets you have, the more work the routers have to do.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I would do to fix this is to </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 concern. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I see integrity checks at the link layer as being more of a network diagnostic than a data integrity mechanism. If you have 5% of packets throwing CRC checks, there is an intermittent problem with the cable or the line that needs fixing. The CRC check does not need to be 100% accurate to be sure. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We might even want to go further and mandate that if a linkis throwing more than x% errors, it MUST be shut down to prevent bogus packets being injected that load up the routers.</div><br></div><div><div class="gmail_default" style="font-size:small">Problem here is that the folk at the lower end of the stack and the folk at the upper end of the stack don't often talk to each other. I know the IETF is allegedly designed to make this happen but it doesn't. Ask a routing person what function the CRC or the MAC address perform today and they go straight into alchemy. </div><br></div></div></div>