[ih] Internet Protocol Implementation Guide

[vinton cerf]

cipher block chaining would certainly help - I think for some methods of
encryption, message indicators can adjust the decryptor to allow for out of
order decryption even when using cipher block chaining to do the
encryption. I am not an expert however.

v


On Thu, Aug 21, 2025 at 10:04 AM John Day <jeanjour at comcast.net> wrote:

>
> Sorry forgot to hit Reply-All
>
>
> Begin forwarded message:
>
> *From: *John Day <jeanjour at comcast.net>
> *Subject: **Re: [ih] Internet Protocol Implementation Guide*
> *Date: *August 21, 2025 at 10:03:07 EDT
> *To: *vinton cerf <vgcerf at gmail.com>
>
> A digital signature across the entire contents of the connection or some
> portion of it would catch a substitution, but that would seem to have to be
> done at an upper layer.
>
> I was thinking more that with a block cipher (applied to each segment),
> one would want to use one of several blockchain techniques, so that
> decrypting one block was dependent on the previous block. (To use the
> original meaning of blockchain.)
>
> Also, this would imply that retransmissions had to be on the same
> boundaries, which was not normally true.
>
> On Aug 21, 2025, at 09:53, vinton cerf <vgcerf at gmail.com> wrote:
>
> wouldn't that depend on either the strength of the error check or digital
> signature or decryption algorithm?
>
> v
>
>
> On Thu, Aug 21, 2025 at 9:49 AM John Day via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> Wouldn’t that be susceptible to a substitution attack?
>>
>> > On Aug 21, 2025, at 09:21, Vint Cerf via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>> >
>> > David, it was always believed that segments might have to be decrypted
>> out
>> > of order if they were encrypted - that was an important design criterion
>> > for packet cryptography but maybe you are thinking of something else? We
>> > assumed the reassembly would take place within a buffer window so they
>> > could be placed in the right part of the buffer before assembly was
>> > completed and the result delivered to the next layer up.
>> >
>> > v
>> >
>> >
>> > On Thu, Aug 21, 2025 at 9:09 AM David Finnigan via Internet-history <
>> > internet-history at elists.isoc.org> wrote:
>> >
>> >> On 20 Aug 2025 4:17 pm, Barbara Denny via Internet-history wrote:
>> >>> Quite some time ago I sent email out with links to the handbooks
>> >>> produced by the NIC at SRI. I don't remember if that email also
>> >>> included the Internet Protocol Implementation Guide.  Sending this
>> >>> message in case this document wasn't included.
>> >>> https://apps.dtic.mil/sti/tr/pdf/ADA153624.pdf
>> >>> The end of the document has an interesting snapshot of the status of
>> >>> TCP/IP implantations as of June 8, 1982.
>> >>> barbara
>> >>
>> >> While looking at the sources for some early TCP implementations, I
>> >> noticed that some of them will process most TCP controls out of order
>> >> (except FIN), so long as the segment sequence fits within the receive
>> >> window. Segment text is always kept in sequence to be delivered to the
>> >> user in correct order, of course.
>> >>
>> >> Who was the one to notice that this was possible, when RFC 793 states
>> >> that segments "are generally queued and processed in sequence number
>> >> order" ?
>> >> --
>> >> Internet-history mailing list
>> >> Internet-history at elists.isoc.org
>> >> https://elists.isoc.org/mailman/listinfo/internet-history
>> >> -
>> >> Unsubscribe:
>> >>
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>> >>
>> >
>> >
>> > --
>> > Please send any postal/overnight deliveries to:
>> > Vint Cerf
>> > Google, LLC
>> > 1900 Reston Metro Plaza, 16th Floor
>> > Reston, VA 20190
>> > +1 (571) 213 1346
>> >
>> >
>> > until further notice
>> > --
>> > Internet-history mailing list
>> > Internet-history at elists.isoc.org
>> > https://elists.isoc.org/mailman/listinfo/internet-history
>> > -
>> > Unsubscribe:
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe:
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>>
>
>
>