We have an interesting case with one of our carriers. Looks like we have worked around it for now, but it is rather odd as they are requiring non standard BGP TCP/IP in links to them.
They are requiring us to send all the BGP TCP packets with a TTL of 1
What is interesting is that some of the big routers do indeed do this, but doing so is against the recommendations for TCP/IP which recommends a TTL of 64. BGP itself makes no mention of TTL. There are Internet standards that say the TTL must be at least the Internet diameter even. So naturally, our BGP does in fact follow this standard and uses a TTL of 64.
Of course, using TTL of 1 was a silly thing anyway as anyone could spoof BGP with a TTL of 1 by setting it to a suitable higher value, though if the reply was TTL of 1 they do not get far. The issue that came up is anyone can spoof a convincing TCP RST with a TTL of one and shut down BGP sessions. This problem is now recognised in other Internet standards which document TTL security where one sets a TTL of 255 and the far end checks it is still 255. Remotely spoofing a TTL of 255 is impossible without compromising the local routers somehow. So that works. Indeed our routers support TTL security.
It seems this is some fire-walling rule, and to be honest I have never seen anyone fire-walling based on TTL. It is not clear what they are trying to protect against. They allow L2TP with normal TTLs.
A simpler firewall would be to do the same as other carriers and have access lists covering which of our IPs can talk to which of their IPs, and not fire-walling on TTL.
This is the same bunch that allowed MAC spoofing on PPPoE links to disrupt and even monitor other people's DSL lines. Thankfully they are fixing that.
It seems however they are insisting that any future services we buy must use this non standard BGP to connect to them.
It is very brave of them.
I guess following the standards is a key factor in deciding which suppliers we will use for new services.
P.S. FireBrick have, of course, modified the TCP stack and BGP and config on the FireBrick BGP routers to support this non standard mode of operation as well as standard TTL security.
Subscribe to:
Post Comments (Atom)
Playing with microphones
The latest LED board designs have included a TDK PDM I2S microphone - the idea was to make sound reactive LED strips. It is tiny (3.5mm x 2...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Not defending the practice - but have been using BGP for long enough to know something of the reasoning behind this...
ReplyDeleteWith an eBGP session, it is generally preferred to configure the session over a directly connected link, so there is no risk of a device in the middle having a different forwarding table and introducing a forwarding loop.
In some cases you do want to have an indirect (aka multihop) session but generally this is a bad idea.
Setting the TTL to 1 is not so much a security measure as a sanity check. Consider a BGP session going over an unnumbered PPP link, where the peer addresses at each end of the link are also the loopback addresses of the routers. If you were to set the TTL to 64, and had an alternate route to your BGP peer with 5 hops (e.g. via a peer at LINX) it is possible that the eBGP session would stay up, even though there is no valid adjacency.
Setting the TTL does not protect you from malicious sources out on the big bad Intertubes, but it can protect you from your own mistakes...
I agree that making it mandatory and calling it a security feature is dumb though.
OK, a sanity check may make sense, though TTL security covers that nicely too :-)
ReplyDeleteBut insisting we send TTL 1 is a tad strange, IMHO. Glad you agree.
We do it with one supplier (Jump Networks Ltd), it doesn't cause us any problems and their reasoning for insisting on it is relatively sound - likewise, we use it on point-to-point links where we are not peering with the loopback interface of either router for the reasons that Russell has already explained.
ReplyDeleteUsually, the admin can say, "My network, my rules!" just as A&A has an Acceptable Use Policy but peering is always a fun one as it is the point where two disparate networks meet therefore AUPs don't always apply (a kind of 'No Mans' Land' for want of a better term).
The point being that one admin may not always see eye to eye with the other admin which is what I suspect has happened here.
The main thing is we cannot see why they insist on it - it is not clear. It is not security, like TTL security would be. The protection from silly mistakes is what helps us so why insist. Indeed for the silly mistakes angle they can send TTL 1 and avoid any issues without insisting on it being TTL 1 from us.
ReplyDeleteThe only comment so far was to stop us peering with another of their customers via the link - but surely, like other carriers do, you just set fire-walling as to what we can peer with to be their routers and only their routers. That has to be more logical.
Just damn strange, in my experience. We have had no issue with transit or peering or other carriers. This lot seem to be pretty unusual and for no good reason.
Oh well.
"to stop us peering with another of their customers"
ReplyDeleteOK. That sounds like a potentially dangerous statement from your carrier.
Firstly, why would they disallow you from peering with another of their customers?
And secondly, if you were to peer with another of their customers, you would need a separate TCP session... Whether your BGP session with the carrier has a TTL 1, 64 or 255 is irrelevant.
Are they saying that they will drop *any* bgp traffic (i.e. 179/tcp) you send to them? I would consider an Internet BGP Transit connection with arbitrary port/protocol filtering to be not fit for purpose.
I guess they may be applying limits to what you are allowed to do with the link address they have assigned. They will probably have registered this under their name as an INFRA-AW assignment, so I guess there could be a valid argument to do this. It is not something that I have ever seen elsewhere though.
It is BGP to support L2Tp to them, so not that bad to say don't peer with other customers. But they could just say that - they don't need firewalls and if they did, then why not lock down IPs we can use.
ReplyDelete