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

[ll1025]

Those wishing to learn more about the TCP Authentication Option feature can see the IETF.org RFC5925 spec.

...Or head straight over to the forums to comment without having bothered to look at the spec.

To answer the questions posed here:

Why do I need this when I have TLS?

TCP-AO is not intended to replace the use of Transport Layer Security
(TLS) [RFC5246], Secure BGP (sBGP) or Secure Origin BGP (soBGP)
[Le09], or any other mechanisms that protect only the TCP data
stream. TCP-AO protects the transport layer, preventing attacks from
disabling the TCP connection itself [RFC4953].

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.

This isn't intended for higher layers of the stack, it's to replace the existing TCP-MD5 spec which is outdated and flawed.

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

The spec mentions both TLS and IPSec, and notes that this is intended for narrow usecases where neither are applicable and to prevent the risk of attacks on the transport layer. For instance, while TLS will protect the session, an attacker can still tamper with the TCP header to cause a RST.

One of the problem statements-- the reasons behind this spec-- can be found, in part, here.

[gavron]

...Or head straight over to the forums to comment without having bothered to look at the spec.

To answer the questions posed here:



TCP-AO is not intended to replace the use of Transport Layer Security
(TLS) [RFC5246], Secure BGP (sBGP) or Secure Origin BGP (soBGP)
[Le09], or any other mechanisms that protect only the TCP data
stream. TCP-AO protects the transport layer, preventing attacks from
disabling the TCP connection itself [RFC4953].



This isn't intended for higher layers of the stack, it's to replace the existing TCP-MD5 spec which is outdated and flawed.



The spec mentions both TLS and IPSec, and notes that this is intended for narrow usecases where neither are applicable and to prevent the risk of attacks on the transport layer. For instance, while TLS will protect the session, an attacker can still tamper with the TCP header to cause a RST.

One of the problem statements-- the reasons behind this spec-- can be found, in part, here.

So there is one practical application for this, and it's to avoid using GTSM for BGP sessions. It adds authentication, but makes a bunch of layering violations. To some people this is an excusable thing (like a MAC layer not being L1 or L2) but to others (like me) it's a purism violation without a just cause.

If you don't mind the layering violations I don't think my argument will be persuasive to you or to Steven. However, in the interest of making it clearer hoping to be undestood... I believe the layering has worked VERY VERY WELL to the point that we could throw IPv6 at it and not have to rewrite millions of applications using socket() and bind(). Breaking layers requires making assumptions, documenting those assumptions, and then hoping future coders will bother to adhere to both of these, or not use that thing we create that broke the layers.

TCP in and of itself is merely a transport protocol, with the inherent lack of auth/crypt/whatever. It's a bidirectional stream of octets. To build upon that we already have mechanisms already discussed above (e.g. SSL, TLS) which are the responsibility of L5 and above to implement using L4. If you continue with the layer model, L5-7 have no way of knowing what services L3 offers OTHER than that octet stream. That's what they count on. That's *ALL* that they count on. If "they" need more, "they" should deploy that specific "more" that they need (auth, crypt, etc.)

Hopefully that represents my viewpoint. I'll stay quiet[er] until something else rises to the top

[jharr]

As others have stated, this is indeed intended to be used primarily by routers running BGP and/or LDP between routing daemons like Bird, FRRouting, Quaga, IOS-XR, Nokia SR-Linux, Junos, EOS, etc. Also, potentially between routers and RPKI validators.

Everyone else is unlikely to see TCP-AO just like they're unlikely to see TCP-MD5. It doesn't make sense in most applications.

Keep in mind that in BGP, you TLS can often be impractical for a few reasons 1) there is no FQDN on a BGP session to establish a cert chain 2) Things like DNS and OCSP don't work because if BGP is down, you probably aren't going to get DNS or OCSP to work 3) copying certs around is a lot of extra work when a pre-shares auth key will do.

There are some efforts to apply TLS to BGP, and maybe the above obstacles really don't matter and I'm wrong. However, TCP-AO and (more prevalently) TCP-MD5 exist in the wild on commercial routing platforms, so it makes sense to have it in Linux to interop with those platforms. And TCP-AO is a lot better than TCP-MD5. It includes things like negotiation, key rotation mechanisms.

Just don't use it for client/server or server/server comms. It doesn't make sense there

[gavron]

As others have stated, this is indeed intended to be used primarily by routers running BGP and/or LDP between routing daemons like Bird, FRRouting, Quaga, IOS-XR, Nokia SR-Linux, Junos, EOS, etc. Also, potentially between routers and RPKI validators.

Everyone else is unlikely to see TCP-AO just like they're unlikely to see TCP-MD5. It doesn't make sense in most applications.

Keep in mind that in BGP, you TLS can often be impractical for a few reasons 1) there is no FQDN on a BGP session to establish a cert chain 2) Things like DNS and OCSP don't work because if BGP is down, you probably aren't going to get DNS or OCSP to work 3) copying certs around is a lot of extra work when a pre-shares auth key will do.

There are some efforts to apply TLS to BGP, and maybe the above obstacles really don't matter and I'm wrong. However, TCP-AO and (more prevalently) TCP-MD5 exist in the wild on commercial routing platforms, so it makes sense to have it in Linux to interop with those platforms. And TCP-AO is a lot better than TCP-MD5. It includes things like negotiation, key rotation mechanisms.

Just don't use it for client/server or server/server comms. It doesn't make sense there

Please see my comment six hours earlier (#11). TCP-AO is a poor replacement for not deploying GTSM. That's an opinion and I spent some time explaining that. BGP and anything else for near-adjacent router-to-router communication doesn't require nor call for anything near the complexity of TCP-AO. Nobody else will need or use it. It's a waste to put it in the Linux kernel other than to support e.g. OpenWRT and its brethren. JunOS is *BSD. Cisco IOS (the original IOS) is neither. I am a huge linux fan (I read Phoronix and support it and Michael...) but I don't expect to see it running a backbone router any time soon.

E

[samualblair]

Please see my comment six hours earlier (#11). TCP-AO is a poor replacement for not deploying GTSM. That's an opinion and I spent some time explaining that. BGP and anything else for near-adjacent router-to-router communication doesn't require nor call for anything near the complexity of TCP-AO. Nobody else will need or use it. It's a waste to put it in the Linux kernel other than to support e.g. OpenWRT and its brethren. JunOS is *BSD. Cisco IOS (the original IOS) is neither. I am a huge linux fan (I read Phoronix and support it and Michael...) but I don't expect to see it running a backbone router any time soon.

E

I agree with most of your comments so far, especially the concern about long term sacrifices due to layering violations.

I am surprised about your last post. You may be right in general, but what about underpinning of Cisco IOS-XE, Cisco NX-OS? Even Juniper’s new os Juniper JunOS-Evolved. Other vendors like F5 TMOS and F5-OS, Cumulus Networks (nvidia owned now), or SONiC? Not to mention smaller stuff like Negate (pfSense people) new OS tnSR. All of these use Linux as base to one degree or another.

Seems to me the trend is toward linux networking, not away from it.

My point is that maybe not all or even majority of protocol stacks, or carrier os (e.g Cisco IOS-XR) will be Linux, but certainly still is a lot of Linux based networking OSes and Stacks in the world. Not just OpenWRT.

[gavron]

I agree with most of your comments so far, especially the concern about long term sacrifices due to layering violations.

I am surprised about your last post. You may be right in general, but what about underpinning of Cisco IOS-XE, Cisco NX-OS? Even Juniper’s new os Juniper JunOS-Evolved. Other vendors like F5 TMOS and F5-OS, Cumulus Networks (nvidia owned now), or SONiC? Not to mention smaller stuff like Negate (pfSense people) new OS tnSR. All of these use Linux as base to one degree or another.

Seems to me the trend is toward linux networking, not away from it.

My point is that maybe not all or even majority of protocol stacks, or carrier os (e.g Cisco IOS-XR) will be Linux, but certainly still is a lot of Linux based networking OSes and Stacks in the world. Not just OpenWRT.

Yes, you make good points about vendors coming in using linux. I don't see that as a longer term strategy since at some point they invariably want to prevent anyone else using their work. FOSS is great to start... but then they get greedy and switch to BSD or MIT licensing. (Note: I'm not a fan of this... just an observer). When they do that they take all they've learned but now the rest of us don't benefit from it.

At that point we (the "we" here is the linux/gnu/foss community) is still maintaining the sw, which is a burden, but get nothing in return. We don't do it for the return... but we also don't do it because we have loads of spare time to implement featues nobody will use.

So, to make this simple... if nobody has a use for this outside of backbone router vendors (and I don't see another play here for this) and there are other options (I've mentioned them) then why should we nice helpful linux/gnu/foss people develop a codebase, then maintain and support it, only to enable those to take it and then copy the constructs to a less liberal licensed model? See e.g. Redhat/CentOS and how that's "working out well." I don't think any rules were violated but a lot of people (including me) are pissed off...

TCP doesn't need auth. There are alternatives to that for BGP and LDP and VPNs and IP/IP tunnels. Any work the real FOSs community does, the fake FOSS people will use to build up their financial warchests and contribute -nothing- in return.

If I'm wrong, I'll apologize. I'm man enough to own that I make mistakes. This one... I don't think I'm in error.

[jharr]

Apologies, I think I misunderstood your original post.

You're right TCP-AO isn't a replacement for GTSM and in most cases, it will do the job better. But there are still times and places where GTSM isn't viable or isn't going to provide a complete solution. Specifically for multihop eBGP sessions (rare but they do exist), iBGP sessions to route reflectors, or RPKI validator sessions.

On the topic of getting Linux support so vendors like Cisco or juniper can make use of it... they have money and I'm not concerned with them being able to patch in TCP-AO themselves. In fact, they already have. IOS-XR uses Linux under the hood since 6.0. I'm more concerned with network interop. What if you're running a route reflector on Linux + FRRouting or Bird? What if you have an RPKI validator on Linux and want to secure that session? What if I'm running SONIC/Hedgehog?

There are also some times in networking where you don't get to choose the requirements, the requirements are thrust upon you by a situation you have no control over.

My point is that 1) I don't expect most people to use TCP-AO and don't think they should 2) I still think it's a welcome feature in the kernel to bring an option for people running networks.

Layer violation or not, the world sometimes won't care and will use it anyway.