When TCP was first invented, was the initial sequence number required to be random?
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
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
10
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
@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
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago
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
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
history
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Dec 30 '18 at 0:41
user11455
663
663
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
user11455 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
10
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
@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
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago
add a comment |
10
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
@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
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago
10
10
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
@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
2 days ago
@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
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago
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).
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
4
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
2 days ago
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
});
}
});
user11455 is a new contributor. Be nice, and check out our Code of Conduct.
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).
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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).
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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).
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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).
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 days ago
jpa
3304
3304
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
jpa is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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.
4
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
2 days ago
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.
4
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
2 days ago
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.
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 Gober
7,66712039
7,66712039
4
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
2 days ago
add a comment |
4
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
2 days ago
4
4
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
2 days ago
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
2 days ago
add a comment |
user11455 is a new contributor. Be nice, and check out our Code of Conduct.
user11455 is a new contributor. Be nice, and check out our Code of Conduct.
user11455 is a new contributor. Be nice, and check out our Code of Conduct.
user11455 is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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
10
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
@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
2 days ago
@Mark Has the DARPA spec included a provision for pranking?
– Leo B.
2 days ago