rfc9187xml2.original.xml   rfc9187.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC793 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.0793.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.1034.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1035.xml">
<!ENTITY RFC1982 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1982.xml">
<!ENTITY RFC5925 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5925.xml">
<!ENTITY RFC7323 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7323.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-touch-sne-02" category="info" ipr="tru <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-touch-sne-02" num
st200902"> ber="9187" submissionType="independent" category="info" ipr="trust200902" obsole
<!-- Generated by id2xml 1.5.0 on 2021-12-09T00:38:40Z --> tes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true"
<?rfc strict="yes"?> version="3">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Sequence Number Extension">Sequence Number Extension for W
indowed Protocols</title>
<author initials="J." surname="Touch" fullname="Joe Touch">
<organization abbrev="Independent consultant"></organization>
<address>
<postal>
<street></street>
<city>Manhattan Beach</city>
<region>CA</region>
<code>90266</code>
<country>USA</country>
</postal>
<phone>+1 (310) 560-0334</phone>
<email>touch@strayalpha.com</email>
</address>
</author>
<date year="2021" month="December"/>
<workgroup>ISE Stream</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract><t> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- Generated by id2xml 1.5.0 on 2021-12-09T00:38:40Z -->
<front>
<title abbrev="Sequence Number Extension">Sequence Number Extension for Wind
owed Protocols</title>
<seriesInfo name="RFC" value="9187"/>
<author initials="J." surname="Touch" fullname="Joe Touch">
<organization abbrev="Independent Consultant"/>
<address>
<postal>
<street/>
<city>Manhattan Beach</city>
<region>CA</region>
<code>90266</code>
<country>United States of America</country>
</postal>
<phone>+1 (310) 560-0334</phone>
<email>touch@strayalpha.com</email>
</address>
</author>
<date year="2022" month="January"/>
<workgroup>ISE Stream</workgroup>
<keyword>TCP-AO</keyword>
<keyword>TCP</keyword>
<abstract>
<t>
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 at the endpoints to avoid the impact of that wrap and reuse numbers at the endpoints to avoid the impact of that wrap and reuse
without transmitting additional information in the packet header. without transmitting additional information in the packet header.
The resulting extended sequence numbers can be used at the endpoints The resulting extended sequence numbers can be used at the endpoints
in encryption and authentication algorithms to ensure input bit in encryption and authentication algorithms to ensure input bit
patterns do not repeat over the lifetime of a connection.</t> patterns do not repeat over the lifetime of a connection.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
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.</t> wrap around during long connections, reusing past values.</t>
<t>
<t> It can be useful for protocols to keep track of this wrap around in
It can be useful for protocols to keep track of this wrap-around in
a separate counter, such that the sequence number and counter a separate counter, such that the sequence number and counter
together form an equivalent number space that need not wrap. This together form an equivalent number space that need not wrap. This
technique was introduced as "sequence number extension" in TCP-AO technique was introduced as "Sequence Number Extension" in the TCP Authentica
<xref target="RFC5925"/>. The example provided there was intended to introduc tion Option (TCP-AO)
e the <xref target="RFC5925" format="default"/>. The example provided there was int
ended to introduce the
concept, but the pseudocode provided is not complete.</t> concept, but the pseudocode provided is not complete.</t>
<t>
<t> 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, reordering, flow control, and congestion control. detection, reordering, flow control, and congestion control.
Limitations in the size of a sequence number protocol field can Limitations in the size of a sequence number protocol field can
limit the ways in which these capabilities can be supported.</t> limit the ways in which these capabilities can be supported.</t>
<t>
<t>
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.</t> provides examples and test cases to simplify that process.</t>
<t>
<t>
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 <xref target="RFC5925"/>. Use of exten authentication protocols, e.g., TCP-AO <xref target="RFC5925" format="default
ded "/>. 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 enable their use in both locations.</t> to enable their use in both locations.</t>
<t>
<t> The remainder of this document describes how SNE can be supported and pro
The remainder of this document describes how sequence number vides the
extension can be supported and provides the pseudocode to pseudocode to
demonstrate how received messages can unambiguously determine the demonstrate how received messages can unambiguously determine the
appropriate extension value, as long as the reordering is appropriate extension value, as long as the reordering is
constrained. <xref target="sect-2"/> provides background on the concept, <xr ef target="sect-3"/> discusses currently known uses of SNE. <xref target="sect-4 "/> discusses how SNE constrained. <xref target="sect-2" format="default"/> provides background on the concept. <xref target="sect-3" format="default"/> discusses currently known uses of SNE. <xref target="sect-4" format="default"/> discusses how SNE
is used in protocol design and how it differs from in-band use of is used in protocol design and how it differs from in-band use of
sequence numbers. <xref target="sect-5"/> provides a framework for testing SN E sequence numbers. <xref target="sect-5" format="default"/> provides a framewo rk for testing SNE
implementations, including example code for the SNE function, and implementations, including example code for the SNE function, and
<xref target="sect-6"/> provides a sequence that can be used by that code for <xref target="sect-6" format="default"/> provides a sequence that can be used
validation. <xref target="sect-7"/> concludes with a discussion of security by that code for
validation. <xref target="sect-7" format="default"/> concludes with a discuss
ion of security
issues.</t> issues.</t>
</section>
</section> <section anchor="sect-2" numbered="true" toc="default">
<name>Background</name>
<section title="Background" anchor="sect-2"><t> <t>
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.</t> messages and detect gaps due to inferred loss.</t>
<t>
<t>
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.</t> range from 0..(2<sup>N</sup>)-1, inclusive.</t>
<t>
<t>
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.</t> of the same value.</t>
<t>
<t>
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 number space. A receiver cannot detect an error in that the number space. A receiver cannot detect an error in that
sequence, but it will incorrectly interpret numbers if reordering sequence, but it will incorrectly interpret numbers if reordering
violates this constraint.</t> violates this constraint.</t>
<t>
<t>
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.</t> never experience a series of values that violate that rule.</t>
<t>
<t>
We define a sequence space as follows:</t> We define a sequence space as follows:</t>
<ul spacing="normal">
<t><list style="symbols"><t>An unsigned integer range from 0..(2^N)-1, i. <li>An unsigned integer within the range of 0..(2<sup>N</sup>)-1, i.e.,
e., for N bits</t> for N bits.</li>
<li>An operation that increments values in that space by K, where K &lt;
<t>An operation that increments values in that space by K, where K &lt; 2 2<sup>(N-1)</sup>, i.e., less than half the range. This operation is used exclu
^(N-1), i.e., less than half the range. This operation is used exclusively by th sively by the transmitter.</li>
e transmitter.</t> <li>An operation that compares two values in that space to determine
their order, e.g., where X&nbsp;&lt;&nbsp;Y implies that X comes before Y.<
<t>An operation that compares two values in that space to determine /li>
their order, e.g., where X &lt; Y implies that X comes before Y</t> </ul>
<t>
</list>
</t>
<t>
We assume that both sides begin with the same initial value, which can be 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) before the anywhere in the space. That value is either assumed (e.g., 0) before the
protocol begins, or coordinated before other messages are exchanged (as protocol begins or coordinated before other messages are exchanged (as
with TCP Initial Sequence Numbers, i.e., ISNs <xref with TCP Initial Sequence Numbers (ISNs) <xref target="RFC0793" format="defau
target="RFC0793"/>). The receiver is assumed to always receive values that lt"/>). It is assumed that the receiver always receives values that
are always within (2^N)-1 but that successive received values never jump are always within (2<sup>N</sup>)-1, but the successive received values never
forward or backward by more than 2^(N-1)-1, i.e., just under half the jump
forward or backward by more than 2<sup>(N-1)</sup>-1, i.e., just under half t
he
range.</t> range.</t>
<t>
<t>
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<sup>(N-1)</sup>-1,
which is typically enforced either by assumption or by explicit which is typically enforced either by assumption or by explicit
endpoint coordination.</t> endpoint coordination.</t>
<t>
<t> An SNE is a separate number space that
A sequence number extension (SNE) is a separate number space that
can be combined with the sequence number to create a larger number can be combined with the sequence number to create a larger number
space that need not wrap around during a connection.</t> space that need not wrap around during a connection.</t>
<t>
<t>
On the transmit side, SNE is trivially accomplished by incrementing a local On the transmit side, SNE is trivially accomplished by incrementing a local
counter once each time the sequence number increment "wraps" around, or by counter once each time the sequence number increment "wraps" around or by
keeping a larger local sequence number whose least-significant part is the keeping a larger local sequence number whose least-significant part is the
message sequence number and most-significant part can be considered the message sequence number and most-significant part can be considered the
SNE. The transmitter typically does not need to maintain an SNE except when SNE. The transmitter typically does not need to maintain an SNE except when
used in local computations, such as for MACs in TCP-AO <xref target="RFC5925" used in local computations, such as for Message Authentication Codes (MACs) i
/>.</t> n TCP-AO <xref target="RFC5925" format="default"/>.</t>
<t>
<t>
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:</t> compute_sne() as follows:</t>
<t indent="6">SNE = compute_sne(seqno)</t>
<figure><artwork><![CDATA[ <t>The compute_sne() function accepts the sequence number seen in a
SNE = compute_sne(seqno) received message
]]></artwork>
</figure>
<t>
Compute_sne() accepts the sequence number seen in a received message
and computes the corresponding SNE. The function includes persistent and computes the corresponding SNE. The function includes persistent
local state that tracks the largest currently received SNE, seqno local state that tracks the largest currently received SNE and seqno
combination. The concatenation of SNE and seqno emulates the combination. The concatenation of SNE and seqno emulates the
equivalent larger sequence number space that can avoid wrap around.</t> equivalent larger sequence number space that can avoid wrap around.</t>
<t>
<t>
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, as long as the series never "jumps" more than half the number SNE, as long as the series never "jumps" more than half the number
space "backward" from the largest value seen "forward".</t> space "backward" from the largest value seen "forward".</t>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Related Discussion</name>
<section title="Related Discussion" anchor="sect-3"><t> <t>
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 <xref target="RFC1034"/><xref target="RFC1035 "/>. The use of considering sequence space wrap <xref target="RFC1034" format="default"/><xre f target="RFC1035" format="default"/>. The use of
wrapped sequence numbers for sliding windows in network protocols wrapped sequence numbers for sliding windows in network protocols
was first described as a sequence number space <xref target="IEN74"/>.</t> was first described as a sequence number space <xref target="IEN74" format="d
efault"/>.</t>
<t> <t>
A more recent discussion describes this as "serial number arithmetic" and def ines a comparison operator it claimed was missing A more recent discussion describes this as "serial number arithmetic" and def ines a comparison operator it claimed was missing
in IEN74 <xref target="RFC1982"/>. That document defines two operations: addi tion in IEN-74 <xref target="RFC1982" format="default"/>. That document defines tw o operations: addition
(presumably shifting the window forward) and comparison (defining (presumably shifting the window forward) and comparison (defining
the order of two values). Addition is defined in that document as the 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 is
defined in that
document by a set of equations therein, but that document does not document by a set of equations therein, but that document does not
provide a way for a receiver to compute the correct equivalent SNE, provide a way for a receiver to compute the correct equivalent SNE,
especially including the potential for sequence number reordering, especially including the potential for sequence number reordering,
as is demonstrated in this document.</t> as is demonstrated in this document.</t>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>Using SNE in Protocol Design</name>
<section title="Using SNE in Protocol Design" anchor="sect-4"><t> <t>
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.</t> messages that might repeat as part of a sequence or stream.</t>
<t>
<t> The size of the sequence number field used within transferred messages
The size of sequence number field used within transferred messages
defines the ability of a protocol to tolerate reordering and gaps, defines the ability of a protocol to tolerate reordering and gaps,
notably limited to half the space of that field. E.g., a field of 8 notably limited to half the space of that field. For example, a field of 8
bits can reorder and detect losses of smaller than 2^7, i.e., 127 bits can reorder and detect losses of smaller than 2<sup>7</sup>, i.e., 127
messages. When used for these purposes - reordering, loss detection, messages. When used for these purposes -- reordering, loss detection,
flow control, and congestion control - the size of the field defines flow control, and congestion control -- the size of the field defines
the limits of those capabilities.</t> the limits of those capabilities.</t>
<t>
<t>
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 sequence number, e.g., to differentiate authentication MACs. the sequence number, e.g., to differentiate authentication MACs.
This sequence number extension (SNE) is never transmitted in This SNE is never transmitted in
messages; the existing rules of sequence number ensure both ends can messages; the existing rules of sequence numbers ensure both ends can
keep track unambiguously - both for new messages and reordered keep track unambiguously -- both for new messages and reordered
messages.</t> messages.</t>
<t>
<t>
The constraints required to use SNE have already been presented as The constraints required to use SNE have already been presented as
background in <xref target="sect-2"/>. The transmitter must never send messag es background in <xref target="sect-2" format="default"/>. 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.</t> the exchange of acknowledgements.</t>
<t>
<t> SNEs are intended for use when it is helpful for both ends to
SNE 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).</t> ensuring unique MACs.</t>
<t>
<t> 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) its tolerance to reordering or gaps. It also cannot improve (thus) its tolerance to reordering or gaps. It also cannot improve
its dynamic range for flow control or congestion control, although its dynamic range for flow control or congestion control, although
there are other somewhat related methods that can, such as window there are other somewhat related methods that can, such as window
scaling <xref target="RFC7323"/> (which increases range at the expense of scaling <xref target="RFC7323" format="default"/> (which increases range at t he expense of
granularity).</t> granularity).</t>
<t>
<t>
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 a transfer sequence, e.g., either because the sequence number of a transfer sequence, e.g., either because the sequence number
field used in its messages never wraparound or because other fields field used in its messages never wrap around or because other fields
provide that disambiguation, such as timestamps.</t> provide that disambiguation, such as timestamps.</t>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Example Code</name>
<section title="Example Code" anchor="sect-5"><t> <t>
The following C code is provided as a verified example of sequence The following C code is provided as a verified example of SNE
number extension from 16 to 32 bits. The code includes both the from 16 to 32 bits. The code includes both the
framework used for validation and the compute_sne() function, the framework used for validation and the compute_sne() function, the
latter of which can be used operationally.</t> latter of which can be used operationally.</t>
<t>
<t>
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.</t> will indicate "ERROR" where applicable.</t>
<sourcecode name="compute_sne.c" type="c" markers="true"><![CDATA[
<figure><artwork><![CDATA[
<CODE BEGINS>
#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 line 392 skipping to change at line 349
// 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 line 423 skipping to change at line 380
((BIG_PREV < BIG_THIS)?"+":"-"), ((BIG_PREV < BIG_THIS)?"+":"-"),
(((distance(BIG_PREV,BIG_THIS)) > 0x7FFFFFFF) (((distance(BIG_PREV,BIG_THIS)) > 0x7FFFFFFF)
? "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> ]]></sourcecode>
]]></artwork> </section>
</figure> <section anchor="sect-6" numbered="true" toc="default">
</section> <name>Validation Suite</name>
<t>
<section title="Validation Suite" anchor="sect-6"><t> The following numbers are used to validate SNE
The following numbers are used to validate sequence number extension variants and are shown in the order they legitimately could be
variants, and are shown in the order they legitimately could be
received. Each line represents a single 64-bit number, represented received. Each line represents a single 64-bit number, represented
as two hexadecimal 32-bit numbers with a space between. The numbers as two hexadecimal 32-bit numbers with a space between. The numbers
are formatted for use in the example code provided in <xref target="sect-5"/> are formatted for use in the example code provided in <xref target="sect-5" f
.</t> ormat="default"/>.</t>
<t>
<t>
A correctly operating extended sequence number system can receive A correctly operating extended sequence number system can receive
the least-significant half (the right side) and compute the correct the least-significant half (the right side) and compute the correct
most-significant half (the left side) correctly. It specifically most-significant half (the left side) correctly. It specifically
tests both forward and backward jumps in received values that tests both forward and backward jumps in received values that
represent legitimate reordering.</t> represent legitimate reordering.</t>
<sourcecode name="sne_testvectors.txt" type="test-vector"><![CDATA[
<figure><artwork><![CDATA[
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
00000001 00000000 00000001 00000000
skipping to change at line 472 skipping to change at line 426
00000002 70000000 00000002 70000000
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
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-7" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations" anchor="sect-7"><t> <t>
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.</t> encryption.</t>
</section>
<section anchor="sect-8" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references>
<name>Informative References</name>
</section> <reference anchor="IEN74">
<front>
<section title="IANA Considerations" anchor="sect-8"><t> <title>Sequence Number Arithmetic</title>
This document contains no IANA issues. This section should be <author initials="W." surname="Plummmer" fullname="William W. Plummmer
removed upon publication as an RFC.</t> ">
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="IEN74"><front>
<title>Sequence Number Arithmetic</title>
<author initials="W." surname="Plummmer" fullname="W. Plummmer">
</author> </author>
<date month="September" year="1978"/>
<date month="September" year="1978"/> </front>
</front> <refcontent>IEN-74</refcontent>
</reference>
<seriesInfo name="IEN" value="74"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</reference> .0793.xml"/>
&RFC793; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC1034; .1034.xml"/>
&RFC1035; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC1982; .1035.xml"/>
&RFC5925; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC7323; .1982.xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<section title="Acknowledgments" anchor="sect-10"><t> .5925.xml"/>
The need for this document was first noted by Juhamatti Kuusisaari <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7323.xml"/>
</references>
<section anchor="sect-10" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The need for this document was first noted by <contact fullname="Juhamatti Ku
usisaari"/>
in April 2020 during discussions of the pseudocode in RFC 5925.</t> in April 2020 during discussions of the pseudocode in RFC 5925.</t>
</section>
<t> </back>
This document was prepared using 2-Word-v2.0.template.dot.</t> </rfc>
</section>
</back>
</rfc>
 End of changes. 65 change blocks. 
251 lines changed or deleted 214 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/