Spamming, NAT, Switching and Labels

Finally! The MPLS specifications have been published. Interesting Informationals talk about Sieve--a handy language that will help you filter spam--and NAT.

By Pete Loshin | Posted Feb 8, 2001
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

January 2001 was a big month, if you've been waiting for the official publication of the core Multiprotocol Label Switching (MPLS) specifications. Though several RFCs have been published over the past few years that were peripherally about MPLS as well as its precursors, the foundational specifications on MPLS and the Label Distribution Protocol (LDP) have finally been released. Table 1 lists the January RFCs.

Other interesting RFCs released in January include a couple of Informationals about Network Address Translation (NAT) as well as a nice new Proposed Standard for Sieve, a mail-filtering language that is positioned as both easy enough for end users to use to sort mail on their clients and powerful enough to help network administrators stop spam at their servers' front door.

Table 1: January 2001 RFCs

Spamming

Unsolicited commercial email (UCE) or unsolicited business email (UBE)--whatever you call it, spam is a major nuisance. It clogs mail servers, fills client mailboxes, and generally makes life difficult for users and network administrators.

Most mail programs, whether for clients or servers, provide some mechanism by which the end-user or netadmin can filter out the junk and sort the rest. However, the filters you set up for a Netscape Communicator user aren't easily transferable to Qualcomm Eudora, Microsoft Outlook, mh (on UNIX systems), or any other email client.

This sounds like a job for the IETF: Come up with a standardizable mechanism for email filtering. Sieve is the answer, as described in RFC 3028, "Sieve: A Mail Filtering Language." Sieve is a very simple programming language designed to be just powerful enough to filter mail, but not so powerful that it can't be safely deployed on a server. There are no variables and no loops, but they aren't necessary for Sieve's defined purpose.

Although Sieve could be an excellent weapon in the constant battle against spam, it must win acceptance in the marketplace. So far, there are few implementations. The biggies, including Microsoft and Lotus, seem to be waiting for consumer demand before they incorporate Sieve in their mail programs, though Cyrusoft International, Inc., does offer Sieve in its mail software. A Sieve resource page is available at http://www.cyrusoft.com/sieve/.

NAT

For some people, network address translation (NAT) is far more annoying than any gnat could ever be. For others, NAT is a tool that lets us continue the day-to-day operations of the Internet without interruption and without having to drop everything and upgrade (or migrate) to IPv6.

Basically, NATs let organizations and individuals use a single globally unique IP address as a front for an entire private network. Using three ranges of IPv4 addresses that have been reserved for private networks (meaning that anyone can use them, as long as they aren't connected to the global Internet), NATs actually translate IP headers originating inside the private network into a form that can be routed through the public Internet using the single official IP address. Headers of inbound packets are also translated, so they can be delivered to the correct host on the private network.

RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)," is an Informational document that updates the definition of NAT provided in RFC 1631. This is a good starting point for anyone interested in how NATs work, what they are, and what they can do.

If you want to know why NATs are anathema to Internet purists and practicing network engineers, read RFC 3027, "Protocol Complications with the IP Network Address Translator." This Informational explains why NATs break applications. The authors begin with a discussion of the attributes of applications that might cause them to not work with NATs. For example, if a protocol requires certain parts of the header to be echoed within the packet payload, it cannot work with NAT, which changes header fields.

Anyone thinking of using NAT, or anyone who must understand how to support applications being used across NATs, should read this RFC. It includes lists of Internet applications that are totally broken by NATs (including IPsec, IKE, Kerberos, X windowing, and r-utilities), applications that can work with NAT if you deploy an application layer gateway as well (including FTP, RSVP, DNS, SMTP, SIP, RealAudio, H.323, and SNMP), and the single application protocol that has been designed to operate happily across a NAT (the Activision Games protocol).

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter