Ietf on Notes

IETF Publishes XMPP RFCs

melo@simplicidade.org (Pedro Melo) — Tue, 05 Oct 2004 11:16:29 +0000

IETF has published the XMPP RFCs. This is great news.

I don’t expect the world of IM to switch to XMPP, but if the large IM networks open up, my only hope is that they choose XMPP as the public protocol. I guess I’m a optimist :)

More about NAT

melo@simplicidade.org (Pedro Melo) — Thu, 05 Aug 2004 19:30:07 +0000

I’m reading the meeting notes of the “behave” BOF at the latest IETF meeting.

There are some remarks that make me nervous. There is a belief that IPv6 will end the need for NAT:

NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms (e.g. 6to4).

Maybe I’m reading this wrong, but I interpret this as: When IPv6 comes, you wont need NAT.

If that’s correct, then I’l be the first to say it: when IPv6 comes, I’ll sill want to use NAT. I don’t use NAT because of IPv4 address space shortage, or lack of features in IPv4. I use NAT because I don’t want the trouble of configuring a firewall in my workstation, and I prefer to have a smallish dedicated router doing it for me. It feels safer. Yes, it is very subjective.

One source of “nat is evil” seems to be rfc 3424. I read it, and I understand the problems they mention there.The third point of my wish list mentioned here seems to be very difficult.

There are also a lot of security considerations about allowing all these incoming connections, but I think that having a protocol to request such communications to happen only make it easier to block/audit/validate those requests.

Also the reliability of the communication is lessen in the sense that now the NAT box has to keep state about it, and if that box fails the communication cannot be routed around to another exit point without going through another round of “expecting connection from X, give me a IP/port pretty please” with the new NAT box.

But as I read rfc 3424 I had to rethink my goals: I might not need a NAT environment but a very smart firewall between me and the world at large when IPv6 gets widespread adoption. The turning point is the C.2 paragraph in the above RFC:

C.2 Real World Home Network Example James Woodyatt provided the following scenario, based on current examples of home networking products: o the customer has existing Internet service from some broadband service provider, using e.g. a DSL line connected to an appliance that integrates a DSL modem with a NAT router/firewall. o these devices are sometimes packaged with automated provisioning firmware, so the customer may view them as part of what their ISP provides them. o later, the customer wants to use a host with only a wireless LAN interface, so they install a wireless access point that ships in its default configuration with NAT and a DHCP server enabled. o after this, the customer has a wired LAN in one private address realm and a wireless LAN in another private address realm. Furthermore, most customers probably have no idea what the phrase "address realm" means and shouldn't have to learn it. All they often know is that the printer server is inaccessible to the wireless laptop computer. (Why? Because the discovery protocol uses UDP multicast with TTL=1, but that's okay because any response would just be dropped by the NAT anyway, because there's no ALG.)

The last paragraph is what made me think: they want this to work in scenarios that, although very plausible, are also very clearly wrong :), and that lead me to the conclusion that I am thinking as a person who knows something about networking, at least enough to understand why this setup is wrong. A less technical person would not know.

Side-note: just yesterday I made this exact setup at my fathers house, and I disabled the DHCP and NAT from the Wireless Router. I also have the exact same setup at home.

I still think that the problems presented in the rfc can be solved, but until I write something about this, I’ll agree that the problem is complex, and that having IPv6, with an address to everybody or everything, its easier to implement and debug.

I just need a damn good firewall it seems.

This is fun.

Aleluia

melo@simplicidade.org (Pedro Melo) — Thu, 05 Aug 2004 18:45:34 +0000

And then, at the end of the tunnel, a light tries to fight against the dark long corridor…

Jabber Architecture: IETF recognizes that NATs exist: "There was a healthy discussion from some saying that the IETF shouldn't enable "those people". The counter argument is that they're going to do it anyway, so we may as well tell them how to do it safely. The turning point in the meeting was when someone at the front asked who in the room was using private address space. About 95% of the people raised their hand. At that point, it was really difficult for people to argue with a straight face that only evil or stupid people had NATs."

Well, it’s about time.

I’m sure someone will point me to some site/url/lava pit for saying this, but I really do like NAT. With the exception of the office in Lisbon, all the other 3 or 4 places I usually work from are behind some sort of Apple or Linksys wireless router doing NAT (more precisely NAPT), and this has become my preferred connection to the Net.

The thing that I like the most is that I don’t have to worry to much about having a very strict personal firewall policy (I trust the persons at the office more that the average Internet person), and that allows me to have a richer local-net experience (becoming much more important in a world of Rendevous^H^H^H^H^H^H^H^H^HOpenTalk).

The problems I have with NAPT are a direct consequence of IETF “nat is evil” mantra. The lack of specs makes certain simple things almost impossible: VoIP, IM File Transfer are the first two that come to mind.

Side-note: I’m still impressed how “just-works-level” Apple has made iChat voice and video-conferencing, even with NAPT on both sides.

But back to NAPT and what I miss: I really would like to see a spec/protocol from IETF that would allow me to write applications that are NAT/NAPT-aware (the second one more important than the first).

The things that I see as most important are:

Am I running behind NAT/NAPT? An application must have a way to discover if they are being NAT/NAPT-ed;
My application must have a way of telling the NAT box that it's expecting a incoming connection TCP or UDP. The NAT box must give back the specific IP address and port number that the remote side must use. Optionally, the request could include the origin IP and port number of such incoming request;
All of the above must work for two or more levels of NAT.

Must check IETF to see if the WG is already created.