Announcement

Collapse
No announcement yet.

TCP Authentication Option "TCP-AO" Support Nears For The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP Authentication Option "TCP-AO" Support Nears For The Linux Kernel

    Phoronix: TCP Authentication Option "TCP-AO" Support Nears For The Linux Kernel

    One of the new Linux networking features we've been looking forward to seeing in the kernel is TCP Authentication Option (TCP-AO / RFC5925) as a means of improving TCP security and authenticity. The eleventh iteration of the TCP-AO patches were posted today for the Linux kernel with it looking like work on this network addition potentially wrapping up soon...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This new standard seems like a really, really stupid idea that's going to backfire on a massive scale if it gets adopted widely enough, due to the eventuality of misconfigurations where people will discard dealing with authentication in higher levels of the stack.

    Comment


    • #3
      Originally posted by emansom View Post
      This new standard seems like a really, really stupid idea that's going to backfire on a massive scale if it gets adopted widely enough, due to the eventuality of misconfigurations where people will discard dealing with authentication in higher levels of the stack.
      I agree. There are layers in networks for a reason and look at how ipsec has seen limited adoption and can be a real PITA for when authentication was shoved into layer 3 instead of layer 4.

      Comment


      • #4
        Why do I need this when I have TLS?

        Comment


        • #5
          Originally posted by uid313 View Post
          Why do I need this when I have TLS?
          To handle the auth upon the creation of the connection itself, rather than just encrypt the traffic.

          Comment


          • #6
            Originally posted by Turbine View Post

            To handle the auth upon the creation of the connection itself, rather than just encrypt the traffic.
            Don't plug in cables: done.

            Comment


            • #7
              Hi. I'm the author of RFC-1535, which has nothing to do with this, but it beats putting in the obligatory resume comments "I've been doing this for umpteen diggity years..."

              Layer4 has no business doing anything other than layer4. TCP-AO has no business existing. It should be up to the higher layers to create whatever mechanism they like to ensure auth or encrypt or both. UID313 mentioned TLS. TLS, SSL, and other mechanisms exist for a reason, and they are great (i.e. they do their job well). There's no need and it's designologically bad to move that functionality to L4 or lower.

              Comment


              • #8
                Originally posted by gavron View Post
                Hi. I'm the author of RFC-1535, which has nothing to do with this, but it beats putting in the obligatory resume comments "I've been doing this for umpteen diggity years..."
                .
                Well then, looking at *this* particular RFC provides an explanation why it is introduced on the TCP layer, namely to counter spoofing attacks. This is something that obviously can not be handled on higher layers.

                Comment


                • #9
                  Originally posted by npwx View Post

                  Well then, looking at *this* particular RFC provides an explanation why it is introduced on the TCP layer, namely to counter spoofing attacks. This is something that obviously can not be handled on higher layers.
                  I think you're conflating L4 wtth L3. In neither case is it the responsibility of the lower layer to prevent its use. That's where layer violation occurs. What you call spoofing is a useful part of reliable network setrvices.

                  Comment


                  • #10
                    Originally posted by gavron View Post
                    Hi. I'm the author of RFC-1535, which has nothing to do with this, but it beats putting in the obligatory resume comments "I've been doing this for umpteen diggity years..."

                    Layer4 has no business doing anything other than layer4. TCP-AO has no business existing. It should be up to the higher layers to create whatever mechanism they like to ensure auth or encrypt or both. UID313 mentioned TLS. TLS, SSL, and other mechanisms exist for a reason, and they are great (i.e. they do their job well). There's no need and it's designologically bad to move that functionality to L4 or lower.
                    TCP-AO is not a new concept it's the successor of rfc2385, however since the usage of MD5 for security features is nowadays kinda sketchy, it's sensible to find a successor that uses a more modern algorithm and is ideally also not forced into using this one algorithm till the end of dawn.

                    Also what is your issue with an implementation in layer3? Having the option to authenticate the TCP stream itself make many attacks a lot harder to perform, as it's not that easy to spoof TCP anymore. Yes ideally the layers above should handle every possible spoofing attack, however it's still an added security by deafault feature. While adoption on hardware will take time, especially with moderns DPU's however it soudln't be an issue to deploy this at scale, even with todays hardware. Despite from the stuggle to implement this, I only see improvements to the internet, if this get's widespread usage.

                    Comment

                    Working...
                    X