When TCP was first invented, was the initial sequence number required to be random?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












16















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?










share|improve this question



















  • 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















16















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?










share|improve this question



















  • 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













16












16








16


1






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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 2 at 21:19









chicks

153110




153110










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












  • 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










2 Answers
2






active

oldest

votes


















29














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).






share|improve this answer






























    13














    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.






    share|improve this answer


















    • 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










    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
    );



    );













    draft saved

    draft discarded


















    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









    29














    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).






    share|improve this answer



























      29














      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).






      share|improve this answer

























        29












        29








        29







        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).






        share|improve this answer













        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).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 30 '18 at 9:22









        jpajpa

        39014




        39014





















            13














            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.






            share|improve this answer


















            • 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















            13














            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.






            share|improve this answer


















            • 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













            13












            13








            13







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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












            • 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

















            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?