Remosi’s Rants

We were discussing today people using RFC1918 for operational networks. People suggested that with good filtering on the edge of the network (disallowing packets entering or leaving with rfc1918 source or destination addresses) that RFC1918 addresses are perfectly usable. I suggest that this is dangerous. People using RFC1918 addresses for routers is especially dangerous. A router that must respond with an error (such as fragmention required, or ttl exceeded) that has only RFC1918 addresses can only respond with a packet sourced from an RFC1918 address. This packet will be dropped at the next “site” border. This now creates a Path MTU Discovery blackhole, or a traceroute “*” on the graph. The former problem is actually a big one. A Path MTU Discovery blackhole is a major problem on the Internet, and is difficult to diagnose. It presents as weird behaviour where you can get small files over the link, but the connection “freezes” if you get more data over the link. [Update: This can occur if you don’t announce your routers IP’s into BGP too] There is no way to track down someone who’s using an RFC1918 address short of logging into every router and monitering it’s ports to figure out which interface the packet(s) are coming in from and repeating the procedure further upstream. This makes reporting broken machines leaking RFC1918 addresses onto the public internet nearly impossible. When the boundary drops are not properly put in place you get all kinds of problems including 2 to 3% of queries at the f root nameserver being from RFC1918 addresses in 2001. People can even multiply the problem by adding RFC1918 to the global DNS database. There are situations where people publish a host that resolves to an RFC1918 address as a low numbered MX. The idea is that the person won’t be able to connect to the host, so they’ll deliver to a higher mx which will then attempt to connect to the lower mx and succeed. Obviously giving no thought as to what happens if the sender can reach a machine with that address, and what will happen if it’s running a mail server. Other problems occur with RFC1918 that aren’t directly associated with using RFC1918 addresses such as bogus queries against the root name servers to reverse lookup rfc1918 addresses. Up to 10% of queries against the root name servers are looking for the reverse lookups for rfc1918 addresses. I’ve personally experienced sshing into a machine that had a rfc1918 address and ending up on a router somewhere inside someone elses network. Since then I beefed up the boundary checks on my network to include reject routes to avoid packets destined to rfc1918 out of my network space. People always swear that they are never going to connect to anyone elses network, and thus it doesn’t matter that they use non unique space. This is proven false time and time again, mostly by the use of vpns but occasionally by merging of companies or by other means. Sorting out a the mess of trying to talk to multiple organisations all using the same RFC1918 address space is a nightmare. Even trying to get transit across someones network is frought with danger as they are almost certainly using rfc1918 somewhere, so your packets are unlikely to reach the far end of their network. I have personally seen situations where someone has brought in a computer with a common RFC1918 address (192.168.1.1) and plugged into a network bringing it down, as that was an address also used by the default gateway. This would be avoided if people didn’t always end up using the same addresses. This can be ameliorated by using addresses out of 172.16.0.0/12 which seems to be mostly unused, presumably because the non multiple of 8 prefix makes calculating netmasks complicated. The major reason we have RFC1918 space is because we just don’t have enough IPv4 addresses to get everyone. A lot of machines should have realworld addresses but don’t, so they are hidden behind NAT and are using RFC1918 addresses because they are the only addresses that can be assured not to be used legitimately elsewhere on the Internet. APNIC (and a lot of others) claim that getting an IPv4 range is very easy. I’d be inclined to believe them in the cases they expect you to be (an ISP or large organisation). I’ve never experienced trying to get IP’s from APNIC. The only thing I’d want IP addresses for would be the Metanet which would almost deserve them. However I don’t have any way of providing routing for those IP’s at a reasonable price, and I dont’ think apnic will give me addresses that I don’t intend to make globally routable. Hrm, perhaps I’ll ask at NZNOG. Also, while in theory getting IPv4 addresses is free, there are a lot of hidden costs. There is a lot of paperwork to fill out (showing how you plan to use the space), Also to get more than one range or a large range, you must be a member of Apnic which is a reasonably pricey proposition for an organisation that doesn’t have the Internet as a primary service. RFC1918 space is often given as a “Security Measure”. This is bogus. The security you get from rfc1918 space is from the address space being filtered. If you cannot configure your filters correctly, then you will be left exposed no matter what address space you use. It’s just as likely that people will be able to route into your network with filtered rfc1918 space, as they will with filtered public address space. Most of the problems on modern networks are quite happy to jump over firewalls, and attack rfc1918 address space as well as they attack any other. Most of the time this is due to people bringing in compromised laptops, fetching infected webpages, reading trojaned emails, using weak passwords, or just simply falling for a phishing scam. So, in conclusion, RFC1918 is bad. There are lots of bad failure modes, including addresses leaking via IP packets (As sources or destinations), inside packets (in DNS queries) or being near malicious in their use of DNS. The small size of the RFC1918 ranges lead to collisions between people which can cause all kinds of weird issues. To resolve these problems we need more addresses so we don’t need to rely on private address space.

Assuming your ISP has multicast, and even assuming that they deliver multicast to you over DSL or some such., the chances of your computer being able to do multicast is slim. I haven’t seen a NAT box that supported multicast routing. Some support RIP for simple routing, but I’ve never seen any that support multicast routing. I could be blind, there might be billions of little routers out there that do multicast routing, but I’ve never noticed them.

So if your a content producer, you just don’t bother with multicast, nobody has it, nobody wants it, and it’s too difficult to setup and maintain for the benefit you gain (since you don’t gain anything, any setup is considered too difficult).

Now I’ve not done much research in the multicast world so I can’t speak as authoratively here as I usually do, but anyway, here’s my idea. Streaming clients and the like should first attempt to connect using multicast, and almost always will fail. Oh well, at least this means if you do have multicast support you don’t need to do anything crazy.

Step two: If you can’t connect using multicast you look up a multicast exploder server, preferably via anycast, but perhaps by a configured ip. You open a control channel to them and state which multicast stream you’re interested in, they open up a port and you send a udp packet to it saying “Yep! Here I am!”. This packet is important as it tells the remote end what IP:Port to send the multicast data to, that works even if you’re behind NAT. The multicast exploder then sends the multicast stream to you unicast over the “connection” you just made. You have to maintain the connection as you usually do with multicast by sending keepalive messages over the control channel.

Step three: If you can’t connect to a multicast exploder, fall back to using the normal unicast methods.

This makes it easy for people who are isolated from the multicast segments of the Internet to easily join them and communicate. It pushes the “Explosion” of traffic out further towards the edges of the Internet (although not as far as multicast itself does). It’s based on similar principles to Teredo and 6to4 which I’ve discussed before, and it should be nearly trivial to implement. So now I guess I have to implement it and convince the IETF to RFC it or something. But first my auth server (see my previous post)

Update: Woot! Someone’s been working on it already

I’m sick of typing usernames and passwords into webpages all across the Internet. Like most people for most “low security” sites I use the same password. I use my browser to remember passwords for me so I don’t have to. I’m lazy. But the thing that irritates me more than having to login to all these different sites is the fact that I have to implement new authentication systems all the time. Create a new website? Write yet another authentication system.

So I thought I should do my own Single Sign On system. My goals:

• It should be secure (duh!).
• You should be able to run your own SSO server.
• It should only do autentication. It says “this user is l33tkiddie but doesn’t do anything about telling you l33tkiddies email address, or credit card information or even name. As a website it’s up to you to collect their details. I’m just doing authentication
• You have the right to not be able to be autenticated without your explicit permission. (Although you may waive this right)
• Be simple enough that anyone can use any server. You don’t need to pay $10,000US per year for permission to use it. It’s an open protocol, anyone can add support for SSO, anyone can run their own SSO server for their own users.
• Authentication servers are not tied down to username/passwords, they are free to authenticate you via other methods (client side SSL certs would be one example).
• You don’t need to trust the site that’s authenticating you. ie, you don’t ever give them your password
• Make phishing attacks hard
• You can have multiple identities. eg, Isomer the Undernet Oper, Perry the programmer, and l33tkiddie the warez courier.

Things I’d like (but not so sure about at the moment)

• Sites not being able to aggregate user data between themselves. Each site gets a userid token which represents you, and each site gets a different token. Two sites can’t figure out you’re the same person without outside help
• The ability for sites to correspond with you without your email address, and for you to know which site sent you the message and be able to revoke a sites ability to contact you at any time.

Things I’m relying on:

• DNS is secure (ha!)
• SSL is secure (heh)
• Users aren’t terminally stupid. (bwahahaha)

So my idea of how you’d implement this is as follows:

• You goto sitea.example.com and it asks you for your username. You type in perry@secure.meta.net.nz
• sitea.example.com sends a redirect to https://secure.meta.net.nz/auth?user=perry@secure.meta.net.nz&return=http://sitea.example.com/login&amp.ccokie1= where cookie1 is a sha1(user:secret:time) where secret is just some secret that sitea knows.
• secure.meta.net.nz authenticates the user, and sends a redirect back to http://sitea.example.com/login&user=perry@secure.meta.net.nz&cookie2= Where cookie2 is a sign(hash(user,cookie1,return),secure.meta.net.nz’s) where it’s signed by secure.meta.net.nz’s private key, which sitea verifies by fetching http://sitea.example.com/public.key (and caching)

So, can anyone see any fundamental flaws in this? This should be safe against MitM attacks (I think). Fishing attacks can be thwarted by showing a different style of login screen based on the username and a secret to secure.meta.net.nz. Unless the fishing site knows secure.meta.net.nz’s secret they can’t replicate the correct login screen and thus the phishing attack is avoided.

Anyway, I’d like to hear peoples opinions. I’m going to try and code it up. The biggest problem at the moment is that things like php don’t seem to have public key functions.

Update: Some notes from various people:

• The antiphishing stuff would provide a different page to every user based on their username. This could change the colours, the layout of the page, the wording, the font (!), icons around the page etc.
• Authentication doesn’t necessarily require a password, you could show people 10 pages with a grid of 10×10 images on them. The user selects the right image in each page, this gives 100**10 different combinations and perhaps would have more entropy than passwords. (since people are unlkely to use their birthdate).
• Authentication could also use SSL client certificates from CACert or something.
• I forgot the timestamp to send back to sitea this prevents replay attacks.
• I forgot to send the original cookie1 back to sitea unmodified so that sitea doesn’t requre any extra storage (like syncookies)