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<mailto:Herbie.Robinson=40stratus....@dmarc.ietf.org>> Sent: Monday, November 13, 2023 2:25 PM To: Templin (US), Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> Cc: int-area@ietf.org<mailto: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<mailto:Fred.L.Templin=40boeing....@dmarc.ietf.org>> Sent: Monday, November 13, 2023 5:19 PM To: Robinson, Herbie <herbie.robin...@stratus.com<mailto:herbie.robin...@stratus.com>>; Tom Herbert <t...@herbertland.com<mailto:t...@herbertland.com>>; Templin (US), Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> Cc: int-area@ietf.org<mailto: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<mailto: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<mailto:tom=40herbertland....@dmarc.ietf.org>>; Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org<mailto:Fred.L.Templin=40boeing....@dmarc.ietf.org>> Cc: int-area@ietf.org<mailto: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<mailto: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<mailto:Fred.L.Templin=40boeing....@dmarc.ietf.org>> Cc: int-area@ietf.org<mailto: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<mailto: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/<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
