Fred, MD5 is insecure, see RFC 9155 for the details.
Cheers, Andy On Mon, Nov 13, 2023 at 6:08 PM Templin (US), Fred L <Fred.L.Templin= 40boeing....@dmarc.ietf.org> wrote: > Herbie, what in your opinion would be the more preferable solution – use > MD5 for which standards > > and implementations are widely deployed, or define new standards and > implementations for CRC128 > > where there is currently no deployment? I think SHA1 is overkill for what > we need, but open to other > > opinions. > > > > Fred > > > > *From:* Templin (US), Fred L > *Sent:* Monday, November 13, 2023 2:27 PM > *To:* 'Robinson, Herbie' <Herbie.Robinson=40stratus....@dmarc.ietf.org> > *Cc:* int-area@ietf.org > *Subject:* RE: [Int-area] [EXTERNAL] Re: A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > I don’t mind entertaining alternatives to MD5 – SHA1? > > > > I looked, but could not find a standard for CRC128 – maybe doesn’t exist? > > > > Fred > > > > *From:* Robinson, Herbie <Herbie.Robinson=40stratus....@dmarc.ietf.org> > *Sent:* Monday, November 13, 2023 2:25 PM > *To:* Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* int-area@ietf.org > *Subject:* RE: [Int-area] [EXTERNAL] Re: A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > EXT email: be mindful of links/attachments. > > > > > There has to be something better than MD5 these days. It’s actually > slower to implement than some newer hashes and overkill at the same time > (because it was designed for crypto). > > > > For that matter, CRCs are really cheap to implement in hardware (a shift > register and a few gates), but they are harder to do in software. > Something to think about. > > > > *From:* Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > *Sent:* Monday, November 13, 2023 5:19 PM > *To:* Robinson, Herbie <herbie.robin...@stratus.com>; Tom Herbert < > t...@herbertland.com>; Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* int-area@ietf.org > *Subject:* RE: [Int-area] [EXTERNAL] Re: A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > *[**EXTERNAL SENDER**: This email originated from outside of Stratus > Technologies. Do not click links or open attachments unless you recognize > the sender and know the content is safe.]* > > > ------------------------------ > > Thank you for this, Herbie – exactly what you describe below would be an > acceptable solution. Let the > > CRC gates do their work, but deliver packets with CRC failures with a > status bit to the driver and/or IP > > layer. Yes, that would satisfy the need. > > > > About CRCs larger than 32 bits for larger frame sizes, the IP Parcels and > Advanced Jumbos draft does > > exactly that: > > > > segment size 0-9K – CRC32 (32 bits) > > segment size 9K-64K – CRC64 (64 bits) > > segment size > 64K – MD5 (128 bits) > > > > Fred > > > > *From:* Int-area <int-area-boun...@ietf.org> *On Behalf Of *Robinson, > Herbie > *Sent:* Monday, November 13, 2023 2:14 PM > *To:* Tom Herbert <tom=40herbertland....@dmarc.ietf.org>; Templin (US), > Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > EXT email: be mindful of links/attachments. > > > > > The NICs I have worked on have a mode that allows packets with CRC > failures to be delivered with a status bit indicating the CRC error. If I > remember correctly, CRC logic amounts to just a handful for gates; so, > arranging to disable it would not be worth the effort at the > standardization level. There is a security/DOS aspect to this although, it > would happen close enough to make the culprit really easy to catch… > > > > Speaking of CRC, 32 bit CRC was considered acceptable back in 1980 for 10K > or so of data. It’s probably not adequate for much more than that. There > have to be more robust things out there with 64 or 128 bit digests, now. > > > > *From:* Int-area <int-area-boun...@ietf.org> *On Behalf Of *Tom Herbert > *Sent:* Monday, November 13, 2023 3:39 PM > *To:* Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > *Cc:* int-area@ietf.org > *Subject:* [EXTERNAL] Re: [Int-area] A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > [EXTERNAL SENDER: This email originated from outside of Stratus > Technologies. Do not click links or open attachments unless you recognize > the sender and know the content is safe.] > > On Mon, Nov 13, 2023 at 11:58 AM Templin (US), Fred L > <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote: > > > > Here is something everyone should read and become familiar with taken > from Section 5 of the latest > > version of "IP Parcels and Advanced Jumbos": > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > > > > A new link service model is offered that will be essential for > supporting air/land/sea/space mobile > > Internetworking. IP Parcels and Advanced Jumbos are the vehicles that > support end-to-end as > > opposed to hop-by-hop link error detection in the new model. > > > > This is a truly transformational concept for the Internet - many may > already know about it, but > > everyone should become aware of it. > > Hi Fred, > > Some comments in line. > <SNIP> > I don't believe disabling the Ethernet CRC is feasible. AFAIK IEEE > 802.3 standards don't allow the Ethernet CRC to be optional. Even if > it were, I doubt any existing NIC hardware or router hardware would > have an API to disable CRC. > > Tom > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
