Re: Outbound SMTP

[Joe St Sauver <joe () OREGON UOREGON EDU>]

Roger Safian <r-safian () NORTHWESTERN EDU> mentioned:

#Are you suggesting that a filter is always binary?  On for the entire
#network or off?

No, clearly there are many different models that different sites may employ.

#If so, then perhaps that's extreme, but, as we all
#know, exceptions can be made.  Fortunately these types of exceptions
#are not that difficult to deal with.

But the exceptions may be difficult to scalably carry forward over time
as the number (and the complexity!) of the exceptions list grows. Special
cases are what kill you.

#This brings me to one of my concerns.  Why do we have to engineer our
#entire networks in one fashion?  How about a research network, where
#port 25 was open, and an administrative network where it's not?  If
#every time I say lets do X, you respond with but so and so needs X,
#we make no progress.

I worry not only about the needs of "so and so," whom we *know* needs X,
but also about all the *other* users who may ALSO need X, but whom we
*don't* know about. Heck, non-technical users may not even know what they
need to ask to have unblocked...

#How about we do X, where practical, and still
#allow so and so the use of an open network?

provided we can also identify and accomodate "so and so's peers", as they
emerge, too.

#If network security
#is going to make significant strides we need to quit catering
#to the least common denominator.

Having a highly tailored network can be a lot of work (as mentioned
above) and cause an increased level of confusion for users and support
staff. Consider, for example, a network that employs customized interior
firewalls on a subnet-by-subnet basis, with each subnet potentially
having a unique/locally customized policy. A network servicing department
A might be quite open, while another network, servicing department B
might be dramatically different, potentially blocking significant numbers
of ports or protocols.

What then, of mobile campus users who travel from one part of campus to
another? Suddenly they face a radically different network experience
depending on where they happen to be, or perhaps *how* they happen to
connect (wired vs. wireless vs. VPN vs. whatever)

Make no mistake, I understand that this is already a reality on many
campuses today due to decentralized approaches to systems and networks, but
clearly it can be a tricky issue -- the network can potentially become
"balkanized" with the network equivalent of different languages, different
currencies, different railroad track spacings, etc., although in the network
case the differences may be more subtle, and only detected when things break.

I think that as we get more and more complex/variable filtering in place,
a widget that probes for and detects various types of blocks, reporting
back on the empirical state of the network for current connectivity, may
become a requirement:

    "You appear to be in a filtered network environment.

    We've detected:

    -- port 80 (web) and port 443 (secure web) traffic is being redirected
       through the local proxy server/content filter at <baz> automatically;
       categories of allowed web content are <X>, <Y> and <Z>; disallowed
       categories of web content are <P>, <Q>, <R> and <S>

    -- port 25 (outbound mail) is blocked; port 25 traffic will be redirected
       to server <foo> automatically

    -- port 53 (DNS) is blocked; your attempt to use the OpenDNS DNS
       servers has been redirected to our local DNS server <bar>
       instead, automatically

    -- H.323 video traffic will not/should not be expected to work

    -- at least some ICMP traffic is being filtered; ping, traceroute
       and some other functions which may rely on ICMP may not work

    -- any identified P2P application traffic will be blocked or shaped
       at will

    -- flash video traffic will be blocked due to traffic volumes

    -- instant messaging, IRC traffic, Microsoft Messenger Service, NNTP and
       Microsoft Networking protocols are blocked

    -- VoIP traffic may be limited or otherwise controlled

    -- VPNs and encrypted/tunnelled traffic, because of the potential for
       those technologies to allow users to circumvent network traffic
       management policies, are also blocked unless approved on a
       case by case basis

    -- inbound email from systems in listed in <blocklist A>, <blocklist B>,
       and <blocklist C> will not be accept

    -- network traffic (of any sort) from sources in <netblock 1>, <netblock
       2>, <netblock 3> will not be blocked

    Advanced Services Status:

    -- RFC1918 private addresses are in use; expect NAT translation to occur

    -- IPv4 support only; IPv6 is not available

    -- R&E network connectivity is via Internet2 (or NLR or whatever)

    -- No direct access to federal mission networks detected

    -- no IP multicast support

    -- the network supports 1500 byte frames; no support for jumbo frames

    -- etc., etc., etc."

At first glance, that sort of report looks pretty complicated, but that's
the sort of network the world is increasingly building, and of course, some
of those policies also look significantly non-"Net Neutral" (if that matters).

Moreover, this is all tremendously confusing to users, who may have no
idea what half or more of that's all about (unless they happen to be users
trying to use an application that happens to be directly or indirectly
impacted, or they are a user trying to exchange traffic with one of the
disallowed destinations, in which case the information listed may be critical
to any attempt at figuring out why a particular application won't work).

All that said, I'll be the first one to admit that I'm as guilty as the
next person of seeking pragmatic solutions to truly hard problems -- I'm
just starting to think that my network karma is catching up with me as
more and more stuff gets blocked or filtered at the network layer. :-;

I could see the possibility of a couple of configurations, one that's
transparent, and one that's filtered within an inch of its life, with
users having the option of choosing between them at connect time, or
jacks that are literally different colors (sort of like the "red and
black" networks for classified and unclassified traffic in some
government agency contexts), but I really worry that if there are *too*
many subtly different menu choices, users (and support staff) may become
very confused. Those of us who are color blind will despair if we need
to track too many different "colors" of networks. :-)

On the other hand, if users have a customized firewall policy *on their
system*, well, at that point they can have a consistent experience on any
unfiltered network connect because they'll be carrying their preferred
filtering settings with them. They'll neither be over filtered or
underfiltered, they'll be "just right" (or at least "just the same") on
any unfiltered network they happen to use.

Sorry about going on so long, I promise I'll let this drop or take it
offline from this point forward. :-)

Regards,

Joe St Sauver (joe () oregon uoregon edu)
http://www.uoregon.edu/~joe/

Disclaimer: all opinions expressed are purely my own.