rfc9187.original   rfc9187.txt 
ISE Stream J. Touch
Internet Draft Independent consultant
Intended status: Informational November 24, 2021
Expires: May 2022
Sequence Number Extension for Windowed Protocols Independent Submission J. Touch
draft-touch-sne-02.txt Request for Comments: 9187 Independent Consultant
Category: Informational January 2022
ISSN: 2070-1721
Sequence Number Extension for Windowed Protocols
Abstract Abstract
Sliding window protocols use finite sequence numbers to determine Sliding window protocols use finite sequence numbers to determine
segment placement and order. These sequence number spaces wrap segment placement and order. These sequence number spaces wrap
around and are reused during the operation of such protocols. This around and are reused during the operation of such protocols. This
document describes a way to extend the size of these sequence document describes a way to extend the size of these sequence numbers
numbers at the endpoints to avoid the impact of that wrap and reuse at the endpoints to avoid the impact of that wrap and reuse without
without transmitting additional information in the packet header. transmitting additional information in the packet header. The
The resulting extended sequence numbers can be used at the endpoints resulting extended sequence numbers can be used at the endpoints in
in encryption and authentication algorithms to ensure input bit encryption and authentication algorithms to ensure input bit patterns
patterns do not repeat over the lifetime of a connection. do not repeat over the lifetime of a connection.
Status of this Memo
This document is not an Internet Standards Track specification; it
is published for informational purposes. This is a contribution to
the RFC Series, independently of any other RFC stream.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document is not an Internet Standards Track specification; it is
months and may be updated, replaced, or obsoleted by other documents published for informational purposes.
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is a contribution to the RFC Series, independently of any other
http://www.ietf.org/ietf/1id-abstracts.txt RFC stream. The RFC Editor has chosen to publish this document at
The list of Internet-Draft Shadow Directories can be accessed at its discretion and makes no statement about its value for
http://www.ietf.org/shadow.html implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on May 24, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9187.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document.
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction
2. Background.....................................................4 2. Background
3. Related Discussion.............................................5 3. Related Discussion
4. Using SNE in Protocol Design...................................6 4. Using SNE in Protocol Design
5. Example Code...................................................7 5. Example Code
6. Validation Suite..............................................10 6. Validation Suite
7. Security Considerations.......................................11 7. Security Considerations
8. IANA Considerations...........................................11 8. IANA Considerations
9. References....................................................11 9. Informative References
9.1. Normative References.....................................11 Acknowledgments
9.2. Informative References...................................11 Author's Address
10. Acknowledgments..............................................12
1. Introduction 1. Introduction
Protocols use sequence numbers to maintain ordering and, in sliding Protocols use sequence numbers to maintain ordering and, in sliding
window systems, to control the amount of outstanding unacknowledged window systems, to control the amount of outstanding unacknowledged
information. These sequence numbers are finite and thus commonly information. These sequence numbers are finite and thus commonly
wrap-around during long connections, reusing past values. wrap around during long connections, reusing past values.
It can be useful for protocols to keep track of this wrap-around in
a separate counter, such that the sequence number and counter
together form an equivalent number space that need not wrap. This
technique was introduced as "sequence number extension" in TCP-AO
[RFC5925]. The example provided there was intended to introduce the It can be useful for protocols to keep track of this wrap around in a
concept, but the pseudocode provided is not complete. separate counter, such that the sequence number and counter together
form an equivalent number space that need not wrap. This technique
was introduced as "Sequence Number Extension" in the TCP
Authentication Option (TCP-AO) [RFC5925]. The example provided there
was intended to introduce the concept, but the pseudocode provided is
not complete.
This document presents the formal requirements for sequence number This document presents the formal requirements for Sequence Number
extension (SNE), a code example, and a check sequence that can be Extension (SNE), a code example, and a check sequence that can be
used to validate this and alternate implementations. Sequence used to validate this and alternate implementations. Sequence
numbers are used in a variety of protocols to support loss numbers are used in a variety of protocols to support loss detection,
detection, reordering, flow control, and congestion control. reordering, flow control, and congestion control. Limitations in the
Limitations in the size of a sequence number protocol field can size of a sequence number protocol field can limit the ways in which
limit the ways in which these capabilities can be supported. these capabilities can be supported.
Under certain conditions, it is possible for both endpoints of a Under certain conditions, it is possible for both endpoints of a
protocol to keep track of sequence number rollover and effectively protocol to keep track of sequence number rollover and effectively
extend the sequence number space without requiring modification of extend the sequence number space without requiring modification of
the sequence number field used within protocol messages. These the sequence number field used within protocol messages. These
conditions assume that the received sequence numbers never vary by conditions assume that the received sequence numbers never vary by
more than half the size of the space of the field used in messages, more than half the size of the space of the field used in messages,
i.e., they never hop forward or backward by more than half that i.e., they never hop forward or backward by more than half that
space. This constraint is typical in sliding window protocols, such space. This constraint is typical in sliding window protocols, such
as TCP. However, although both ends can track rollover as TCP. However, although both ends can track rollover
unambiguously, doing so can be surprizingly complex. This document unambiguously, doing so can be surprisingly complex. This document
provides examples and test cases to simplify that process. provides examples and test cases to simplify that process.
This document is intended for protocol designers who seek to use This document is intended for protocol designers who seek to use
larger sequence numbers at the endpoints without needing to extend larger sequence numbers at the endpoints without needing to extend
the sequence number field used in messages, such as for the sequence number field used in messages, such as for
authentication protocols, e.g., TCP-AO [RFC5925]. Use of extended authentication protocols, e.g., TCP-AO [RFC5925]. Use of extended
sequence numbers should be part of a protocol specification, so that sequence numbers should be part of a protocol specification so that
both endpoints can ensure they comply with the requirements needed both endpoints can ensure they comply with the requirements needed to
to enable their use in both locations. enable their use in both locations.
The remainder of this document describes how sequence number The remainder of this document describes how SNE can be supported and
extension can be supported and provides the pseudocode to provides the pseudocode to demonstrate how received messages can
demonstrate how received messages can unambiguously determine the unambiguously determine the appropriate extension value, as long as
appropriate extension value, as long as the reordering is the reordering is constrained. Section 2 provides background on the
constrained. Section 2 provides background on the concept, Section concept. Section 3 discusses currently known uses of SNE. Section 4
3 discusses currently known uses of SNE. Section 4 discusses how SNE discusses how SNE is used in protocol design and how it differs from
is used in protocol design and how it differs from in-band use of in-band use of sequence numbers. Section 5 provides a framework for
sequence numbers. Section 5 provides a framework for testing SNE testing SNE implementations, including example code for the SNE
implementations, including example code for the SNE function, and function, and Section 6 provides a sequence that can be used by that
Section 6 provides a sequence that can be used by that code for code for validation. Section 7 concludes with a discussion of
validation. Section 7 concludes with a discussion of security security issues.
issues.
2. Background 2. Background
Protocols use sequence numbers to maintain message order. The Protocols use sequence numbers to maintain message order. The
transmitter typically increments them either once per message or by transmitter typically increments them either once per message or by
the length of the message. The receiver uses them to reorder the length of the message. The receiver uses them to reorder
messages and detect gaps due to inferred loss. messages and detect gaps due to inferred loss.
Sequence numbers are represented within those messages (e.g., in the Sequence numbers are represented within those messages (e.g., in the
headers) as values of a finite, unsigned number space. This space is headers) as values of a finite, unsigned number space. This space is
typically represented in a fixed-length bit string, whose values typically represented in a fixed-length bit string, whose values
range from [0..(2^N)-1], inclusive. range from 0..(2^N)-1, inclusive.
The use of finite representations has repercussions on the use of The use of finite representations has repercussions on the use of
these values at both the transmitter and receiver. Without these values at both the transmitter and receiver. Without
additional constraints, when the number space "wraps around", it additional constraints, when the number space "wraps around", it
would be impossible for the receiver to distinguish between the uses would be impossible for the receiver to distinguish between the uses
of the same value. of the same value.
As a consequence, additional constraints are required. Transmitters As a consequence, additional constraints are required. Transmitters
are typically required to limit reuse until they can assume that are typically required to limit reuse until they can assume that
receivers would successfully differentiate the two uses of the same receivers would successfully differentiate the two uses of the same
value. The receiver always interprets values it sees based on the value. The receiver always interprets values it sees based on the
assumption that successive values never differ by just under half assumption that successive values never differ by just under half the
the number space. A receiver cannot detect an error in that number space. A receiver cannot detect an error in that sequence,
sequence, but it will incorrectly interpret numbers if reordering but it will incorrectly interpret numbers if reordering violates this
violates this constraint. constraint.
The constraint requires that "forward" values advance the values by The constraint requires that "forward" values advance the values by
less than half the sequence number space and ensuring that receivers less than half the sequence number space, ensuring that receivers
never experience a series of values that violate that rule. never experience a series of values that violate that rule.
We define a sequence space as follows: We define a sequence space as follows:
o An unsigned integer range from 0..(2^N)-1, i.e., for N bits * An unsigned integer within the range of 0..(2^N)-1, i.e., for N
bits.
o An operation that increments values in that space by K, where K < * An operation that increments values in that space by K, where K <
2^(N-1), i.e., less than half the range. This operation is used 2^(N-1), i.e., less than half the range. This operation is used
exclusively by the transmitter. exclusively by the transmitter.
o An operation that compares two values in that space to determine * An operation that compares two values in that space to determine
their order, e.g., where X < Y implies that X comes before Y their order, e.g., where X < Y implies that X comes before Y.
We assume that both sides begin with the same initial value, which We assume that both sides begin with the same initial value, which
can be anywhere in the space. That value is either assumed (e.g., 0) can be anywhere in the space. That value is either assumed (e.g., 0)
before the protocol begins, or coordinated before other messages are before the protocol begins or coordinated before other messages are
exchanged (as with TCP Initial Sequence Numbers, i.e., ISNs exchanged (as with TCP Initial Sequence Numbers (ISNs) [RFC0793]).
[RFC793]). The receiver is assumed to always receive values that are It is assumed that the receiver always receives values that are
always within (2^N)-1 but that successive received values never jump always within (2^N)-1, but the successive received values never jump
forward or backward by more than 2^(N-1)-1, i.e., just under half forward or backward by more than 2^(N-1)-1, i.e., just under half the
the range. range.
No other operations are supported. The transmitter is not permitted No other operations are supported. The transmitter is not permitted
to "backup", such that values are always used in "increment" order. to "backup", such that values are always used in "increment" order.
The receiver cannot experience loss or gaps larger than 2^(N-1)-1, The receiver cannot experience loss or gaps larger than 2^(N-1)-1,
which is typically enforced either by assumption or by explicit which is typically enforced either by assumption or by explicit
endpoint coordination. endpoint coordination.
A sequence number extension (SNE) is a separate number space that An SNE is a separate number space that can be combined with the
can be combined with the sequence number to create a larger number sequence number to create a larger number space that need not wrap
space that need not wrap around during a connection. around during a connection.
On the transmit side, SNE is trivially accomplished by incrementing On the transmit side, SNE is trivially accomplished by incrementing a
a local counter once each time the sequence number increment "wraps" local counter once each time the sequence number increment "wraps"
around, or by keeping a larger local sequence number whose least- around or by keeping a larger local sequence number whose least-
significant part is the message sequence number and most-significant significant part is the message sequence number and most-significant
part can be considered the SNE. The transmitter typically does not part can be considered the SNE. The transmitter typically does not
need to maintain an SNE except when used in local computations, such need to maintain an SNE except when used in local computations, such
as for MACs in TCP-AO [RFC5925]. as for Message Authentication Codes (MACs) in TCP-AO [RFC5925].
The goal of this document is to demonstrate that SNE can be The goal of this document is to demonstrate that SNE can be
accomplished on the receiver side without transmitting additional accomplished on the receiver side without transmitting additional
information in messages. It defines the stateful function information in messages. It defines the stateful function
compute_sne() as follows: compute_sne() as follows:
SNE = compute_sne(seqno) SNE = compute_sne(seqno)
Compute_sne() accepts the sequence number seen in a received message The compute_sne() function accepts the sequence number seen in a
and computes the corresponding SNE. The function includes persistent received message and computes the corresponding SNE. The function
local state that tracks the largest currently received SNE, seqno includes persistent local state that tracks the largest currently
combination. The concatenation of SNE and seqno emulates the received SNE and seqno combination. The concatenation of SNE and
equivalent larger sequence number space that can avoid wrap around. seqno emulates the equivalent larger sequence number space that can
avoid wrap around.
Note that the function defined here is capable of receiving any Note that the function defined here is capable of receiving any
series of seqno values and computing their correct corresponding series of seqno values and computing their correct corresponding SNE,
SNE, as long as the series never "jumps" more than half the number as long as the series never "jumps" more than half the number space
space "backward" from the largest value seen "forward". "backward" from the largest value seen "forward".
3. Related Discussion 3. Related Discussion
The DNS uses sequence numbers to determine when a Start of Authority The DNS uses sequence numbers to determine when a Start of Authority
(SOA) serial number is more recent than a previous one, even (SOA) serial number is more recent than a previous one, even
considering sequence space wrap [RFC1034][RFC1035]. The use of considering sequence space wrap [RFC1034][RFC1035]. The use of
wrapped sequence numbers for sliding windows in network protocols wrapped sequence numbers for sliding windows in network protocols was
was first described as a sequence number space [IEN74]. first described as a sequence number space [IEN74].
A more recent discussion describes this as "serial number A more recent discussion describes this as "serial number arithmetic"
arithmetic" and defines a comparison operator it claimed was missing and defines a comparison operator it claimed was missing in IEN-74
in IEN74 [RFC1982]. That document defines two operations: addition [RFC1982]. That document defines two operations: addition
(presumably shifting the window forward) and comparison (defining (presumably shifting the window forward) and comparison (defining the
the order of two values). Addition is defined in that document as order of two values). Addition is defined in that document as
limited to value of 0..windowsize/2-1. Comparison is defined in that limited to values within the range of 0..windowsize/2-1. Comparison
document by a set of equations therein, but that document does not is defined in that document by a set of equations therein, but that
provide a way for a receiver to compute the correct equivalent SNE, document does not provide a way for a receiver to compute the correct
especially including the potential for sequence number reordering, equivalent SNE, especially including the potential for sequence
as is demonstrated in this document. number reordering, as is demonstrated in this document.
4. Using SNE in Protocol Design 4. Using SNE in Protocol Design
As noted in the introduction, message sequence numbers enable As noted in the introduction, message sequence numbers enable
reordering, loss detection, flow control, and congestion control. reordering, loss detection, flow control, and congestion control.
They are also used to differentiate otherwise potentially identical They are also used to differentiate otherwise potentially identical
messages that might repeat as part of a sequence or stream. messages that might repeat as part of a sequence or stream.
The size of sequence number field used within transferred messages The size of the sequence number field used within transferred
defines the ability of a protocol to tolerate reordering and gaps, messages defines the ability of a protocol to tolerate reordering and
notably limited to half the space of that field. E.g., a field of 8 gaps, notably limited to half the space of that field. For example,
bits can reorder and detect losses of smaller than 2^7, i.e., 127 a field of 8 bits can reorder and detect losses of smaller than 2^7,
messages. When used for these purposes - reordering, loss detection, i.e., 127 messages. When used for these purposes -- reordering, loss
flow control, and congestion control - the size of the field defines detection, flow control, and congestion control -- the size of the
the limits of those capabilities. field defines the limits of those capabilities.
Sequence numbers are also used to differentiate messages; when used Sequence numbers are also used to differentiate messages; when used
this way, they can be problematic if they repeat for otherwise this way, they can be problematic if they repeat for otherwise
identical messages. Protocols using sequence numbers tolerate that identical messages. Protocols using sequence numbers tolerate that
repetition because they are aware of the rollover of these sequence repetition because they are aware of the rollover of these sequence
number spaces at both endpoints. In some cases, it can be useful to number spaces at both endpoints. In some cases, it can be useful to
track this rollover and use the rollover count as an extension to track this rollover and use the rollover count as an extension to the
the sequence number, e.g., to differentiate authentication MACs. sequence number, e.g., to differentiate authentication MACs. This
This sequence number extension (SNE) is never transmitted in SNE is never transmitted in messages; the existing rules of sequence
messages; the existing rules of sequence number ensure both ends can numbers ensure both ends can keep track unambiguously -- both for new
keep track unambiguously - both for new messages and reordered messages and reordered messages.
messages.
The constraints required to use SNE have already been presented as The constraints required to use SNE have already been presented as
background in Section 2. The transmitter must never send messages background in Section 2. The transmitter must never send messages
out of sequence beyond half the range of the sequence number field out of sequence beyond half the range of the sequence number field
used in messages. A receiver uses this assumption to interpret used in messages. A receiver uses this assumption to interpret
whether received numbers are part of pre-wrap sequences or post-wrap whether received numbers are part of pre-wrap sequences or post-wrap
sequences. Note that a receiver cannot enforce or detect if the sequences. Note that a receiver cannot enforce or detect if the
transmitter has violated these assumptions on its own; it relies on transmitter has violated these assumptions on its own; it relies on
explicit coordination to ensure this property is maintained, such as explicit coordination to ensure this property is maintained, such as
the exchange of acknowledgements. the exchange of acknowledgements.
SNE are intended for use when it is helpful for both ends to SNEs are intended for use when it is helpful for both ends to
unambiguously determine whether the sequence number in a message has unambiguously determine whether the sequence number in a message has
wrapped, and whether a received message is pre-wrap or post-wrap for wrapped and whether a received message is pre-wrap or post-wrap for
each such wrap. This can be used by both endpoints to ensure all each such wrap. This can be used by both endpoints to ensure all
messages of arbitrarily long sequences can be differentiated, e.g., messages of arbitrarily long sequences can be differentiated, e.g.,
ensuring unique message authentication codes (MACs). ensuring unique MACs.
SNE does not extend the actual sequence space of a protocol, or SNE does not extend the actual sequence space of a protocol or (thus)
(thus) its tolerance to reordering or gaps. It also cannot improve its tolerance to reordering or gaps. It also cannot improve its
its dynamic range for flow control or congestion control, although dynamic range for flow control or congestion control, although there
there are other somewhat related methods that can, such as window are other somewhat related methods that can, such as window scaling
scaling [RFC7323] (which increases range at the expense of [RFC7323] (which increases range at the expense of granularity).
granularity).
SNE is not needed if messages are already unique over the entirety SNE is not needed if messages are already unique over the entirety of
of a transfer sequence, e.g., either because the sequence number a transfer sequence, e.g., either because the sequence number field
field used in its messages never wraparound or because other fields used in its messages never wrap around or because other fields
provide that disambiguation, such as timestamps. provide that disambiguation, such as timestamps.
5. Example Code 5. Example Code
The following C code is provided as a verified example of sequence The following C code is provided as a verified example of SNE from 16
number extension from 16 to 32 bits. The code includes both the to 32 bits. The code includes both the framework used for validation
framework used for validation and the compute_sne() function, the and the compute_sne() function, the latter of which can be used
latter of which can be used operationally. operationally.
A correct test will indicate "OK" for each test. An incorrect test A correct test will indicate "OK" for each test. An incorrect test
will indicate "ERROR" where applicable. will indicate "ERROR" where applicable.
<CODE BEGINS> <CODE BEGINS> file "compute_sne.c"
#include <stdio.h> #include <stdio.h>
#include <sys/param.h> #include <sys/param.h>
#define distance(x,y) (((x)<(y))?((y)-(x)):((x)-(y))) #define distance(x,y) (((x)<(y))?((y)-(x)):((x)-(y)))
#define SNEDEBUG 1 #define SNEDEBUG 1
// This is the core code, stand-alone, to compute SNE from seqno // This is the core code, stand-alone, to compute SNE from seqno
// >> replace this function with your own code to test alternates // >> replace this function with your own code to test alternates
unsigned long compute_sne(unsigned long seqno) { unsigned long compute_sne(unsigned long seqno) {
skipping to change at page 9, line 25 skipping to change at line 368
// to received SEQ // to received SEQ
// variables used to validate the computed SNE: // variables used to validate the computed SNE:
unsigned long SEG_HIGH; // input - xmitter side SNE unsigned long SEG_HIGH; // input - xmitter side SNE
// -> SNE should match this value // -> SNE should match this value
unsigned long long BIG_PREV; // prev 64-bit total seqno unsigned long long BIG_PREV; // prev 64-bit total seqno
unsigned long long BIG_THIS = 0; // current 64-bit total seqno unsigned long long BIG_THIS = 0; // current 64-bit total seqno
// -> THIS, PREV should never jump // -> THIS, PREV should never jump
// more than half the SEQ space // more than half the SEQ space
char *prompt = "Hex input (2 groups of 8 hex chars with a char *prompt = "Input hex numbers only (0x is optional)\n\n")
space): "; "\tHex input\n"
"\t(2 hex numbers separated by whitespace,"
fprintf(stderr,"Input hex numbers only (0x is optional)\n\n"); "each with 8 or fewer digits)";
fprintf(stderr,"%s\n",prompt); fprintf(stderr,"%s\n",prompt);
while (scanf("%lx %lx",&SEG_HIGH,&SEG_SEQ) == 2) { while (scanf("%lx %lx",&SEG_HIGH,&SEG_SEQ) == 2) {
BIG_PREV = BIG_THIS; BIG_PREV = BIG_THIS;
BIG_THIS = (((unsigned long long)SEG_HIGH) << 32) BIG_THIS = (((unsigned long long)SEG_HIGH) << 32)
| ((unsigned long long)SEG_SEQ); | ((unsigned long long)SEG_SEQ);
// given SEG_SEQ, compute SNE // given SEG_SEQ, compute SNE
SNE = compute_sne(SEG_SEQ); SNE = compute_sne(SEG_SEQ);
skipping to change at page 10, line 17 skipping to change at line 401
? "ILLEGAL JUMP" : ".")); ? "ILLEGAL JUMP" : "."));
fprintf(stderr,"\n"); fprintf(stderr,"\n");
fprintf(stderr,"\n"); fprintf(stderr,"\n");
fprintf(stderr,"%s\n",prompt); fprintf(stderr,"%s\n",prompt);
} }
} }
<CODE ENDS> <CODE ENDS>
6. Validation Suite 6. Validation Suite
The following numbers are used to validate sequence number extension The following numbers are used to validate SNE variants and are shown
variants, and are shown in the order they legitimately could be in the order they legitimately could be received. Each line
received. Each line represents a single 64-bit number, represented represents a single 64-bit number, represented as two hexadecimal
as two hexadecimal 32-bit numbers with a space between. The numbers 32-bit numbers with a space between. The numbers are formatted for
are formatted for use in the example code provided in Section 5. use in the example code provided in Section 5.
A correctly operating extended sequence number system can receive A correctly operating extended sequence number system can receive the
the least-significant half (the right side) and compute the correct least-significant half (the right side) and compute the correct most-
most-significant half (the left side) correctly. It specifically significant half (the left side) correctly. It specifically tests
tests both forward and backward jumps in received values that both forward and backward jumps in received values that represent
represent legitimate reordering. legitimate reordering.
00000000 00000000 00000000 00000000
00000000 30000000 00000000 30000000
00000000 90000000 00000000 90000000
00000000 70000000 00000000 70000000
00000000 a0000000 00000000 a0000000
00000001 00000001 00000001 00000001
00000000 e0000000 00000000 e0000000
00000001 00000000 00000001 00000000
00000001 7fffffff 00000001 7fffffff
skipping to change at page 11, line 16 skipping to change at line 445
00000002 A0000000 00000002 A0000000
00000003 00004000 00000003 00004000
00000002 D0000000 00000002 D0000000
00000003 20000000 00000003 20000000
00000003 90000000 00000003 90000000
00000003 70000000 00000003 70000000
00000003 A0000000 00000003 A0000000
00000004 00004000 00000004 00004000
00000003 D0000000 00000003 D0000000
7. Security Considerations 7. Security Considerations
Sequence numbers and their extensions can be useful in a variety of Sequence numbers and their extensions can be useful in a variety of
security contexts. Because the extension part (most significant security contexts. Because the extension part (most-significant
half) is determined by the previously exchanged sequence values half) is determined by the previously exchanged sequence values
(least significant half), the extension should not be considered as (least-significant half), the extension should not be considered as
adding entropy for the purposes of message authentication or adding entropy for the purposes of message authentication or
encryption. encryption.
8. IANA Considerations 8. IANA Considerations
This document contains no IANA issues. This section should be
removed upon publication as an RFC.
9. References
9.1. Normative References
9.2. Informative References This document has no IANA actions.
[IEN74] Plummmer, W., "Sequence Number Arithmetic," IEN 74, Sept. 9. Informative References
1978.
[RFC793] Postel, J., "Transmission Control Protocol," RFC 793, [IEN74] Plummmer, W., "Sequence Number Arithmetic", IEN-74,
September 1981. September 1978.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities," [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 1034, Nov. 1987. RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
Specification," Nov. 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic," RFC 1982, [RFC1035] Mockapetris, P., "Domain names - implementation and
Aug. 1996. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
Option," RFC 5925, June 2010. DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC7323] Borman, D., D. Braden, V. Jacobson, R. Scheffenegger, Ed., [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
"TCP Extensions for High Performance" RFC 7323, Sep. 2014. Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
10. Acknowledgments [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
The need for this document was first noted by Juhamatti Kuusisaari Acknowledgments
in April 2020 during discussions of the pseudocode in RFC 5925.
This document was prepared using 2-Word-v2.0.template.dot. The need for this document was first noted by Juhamatti Kuusisaari in
April 2020 during discussions of the pseudocode in RFC 5925.
Authors' Addresses Author's Address
Joe Touch Joe Touch
Manhattan Beach, CA 90266 USA Manhattan Beach, CA 90266
United States of America
Phone: +1 (310) 560-0334 Phone: +1 (310) 560-0334
Email: touch@strayalpha.com Email: touch@strayalpha.com
 End of changes. 80 change blocks. 
241 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/