When TCP was first invented, was the initial sequence number required to be random?
Clash Royale CLAN TAG#URR8PPP
In current time, when a TCP connection is initiated, the initial sequence number is required to be random.
But I am wondering, when TCP was first invented, was the initial sequence number required to be random, or was this requirement added later?
history network internet
edited Jan 2 at 21:19
chicks
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
add a comment |
In current time, when a TCP connection is initiated, the initial sequence number is required to be random.
But I am wondering, when TCP was first invented, was the initial sequence number required to be random, or was this requirement added later?
history network internet
edited Jan 2 at 21:19
chicks
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
11
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
2
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01
add a comment |
In current time, when a TCP connection is initiated, the initial sequence number is required to be random.
But I am wondering, when TCP was first invented, was the initial sequence number required to be random, or was this requirement added later?
history network internet
edited Jan 2 at 21:19
chicks
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
In current time, when a TCP connection is initiated, the initial sequence number is required to be random.
But I am wondering, when TCP was first invented, was the initial sequence number required to be random, or was this requirement added later?
history network internet
history network internet
edited Jan 2 at 21:19
chicks
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
edited Jan 2 at 21:19
chicks
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
edited Jan 2 at 21:19
chicks
153110
edited Jan 2 at 21:19
chicks
153110
edited Jan 2 at 21:19
chicks
153110
153110
asked Dec 30 '18 at 0:41
user11455user11455
813
asked Dec 30 '18 at 0:41
user11455user11455
813
asked Dec 30 '18 at 0:41
user11455user11455
813
813
11
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
2
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01
add a comment |
11
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
2
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01
11
11
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
2
2
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01
add a comment |
2 Answers
2
active
oldest
votes
The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:
To avoid confusion we must prevent segments from one incarnation of
a connection from being used while the same sequence numbers may
still be present in the network from an earlier incarnation. We
want to assure this, even if a TCP crashes and loses all knowledge
of the sequence numbers it has been using. When new connections
are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN. The generator is bound to a
(possibly fictitious) 32 bit clock whose low order bit is
incremented roughly every 4 microseconds.
So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.
Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.
This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).
answered Dec 30 '18 at 9:22
jpajpa
39014
add a comment |
It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.
For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "648"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8605%2fwhen-tcp-was-first-invented-was-the-initial-sequence-number-required-to-be-rand%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:
To avoid confusion we must prevent segments from one incarnation of
a connection from being used while the same sequence numbers may
still be present in the network from an earlier incarnation. We
want to assure this, even if a TCP crashes and loses all knowledge
of the sequence numbers it has been using. When new connections
are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN. The generator is bound to a
(possibly fictitious) 32 bit clock whose low order bit is
incremented roughly every 4 microseconds.
So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.
Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.
This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).
answered Dec 30 '18 at 9:22
jpajpa
39014
add a comment |
The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:
To avoid confusion we must prevent segments from one incarnation of
a connection from being used while the same sequence numbers may
still be present in the network from an earlier incarnation. We
want to assure this, even if a TCP crashes and loses all knowledge
of the sequence numbers it has been using. When new connections
are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN. The generator is bound to a
(possibly fictitious) 32 bit clock whose low order bit is
incremented roughly every 4 microseconds.
So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.
Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.
This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).
answered Dec 30 '18 at 9:22
jpajpa
39014
add a comment |
The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:
To avoid confusion we must prevent segments from one incarnation of
a connection from being used while the same sequence numbers may
still be present in the network from an earlier incarnation. We
want to assure this, even if a TCP crashes and loses all knowledge
of the sequence numbers it has been using. When new connections
are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN. The generator is bound to a
(possibly fictitious) 32 bit clock whose low order bit is
incremented roughly every 4 microseconds.
So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.
Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.
This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).
answered Dec 30 '18 at 9:22
jpajpa
39014
The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:
To avoid confusion we must prevent segments from one incarnation of
a connection from being used while the same sequence numbers may
still be present in the network from an earlier incarnation. We
want to assure this, even if a TCP crashes and loses all knowledge
of the sequence numbers it has been using. When new connections
are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN. The generator is bound to a
(possibly fictitious) 32 bit clock whose low order bit is
incremented roughly every 4 microseconds.
So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.
Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.
This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).
answered Dec 30 '18 at 9:22
jpajpa
39014
answered Dec 30 '18 at 9:22
jpajpa
39014
answered Dec 30 '18 at 9:22
jpajpa
39014
answered Dec 30 '18 at 9:22
jpajpa
39014
39014
add a comment |
add a comment |
It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.
For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
add a comment |
It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.
For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
add a comment |
It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.
For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.
For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
answered Dec 30 '18 at 3:53
Ken GoberKen Gober
7,70712039
7,70712039
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
add a comment |
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
5
5
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
– Mark
Dec 30 '18 at 20:37
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
– supercat
Jan 2 at 22:15
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8605%2fwhen-tcp-was-first-invented-was-the-initial-sequence-number-required-to-be-rand%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
11
When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
– Leo B.
Dec 30 '18 at 4:28
2
@LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
– Mark
Dec 30 '18 at 20:30
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
Dec 30 '18 at 21:01