[Top] [All Lists]

Re: SMTP and Kerberos

2011-11-04 17:07:50

On 11/4/11 5:46 AM, Hector Santos wrote:
 Douglas Otis wrote:
>> The way I see it, practically speaking, Ipv6 will bring back the
>> old simple solution of using "Allow IP Relay Tables" and the
>> "Roaming user" issue would be a thing of the past.
> Please notice currently there are 228,848 billion announced IPv6
> /64 equivalent prefixes. A size 65k larger than the entire IPv4
> unicast space. Also note this space is growing exponentially,
> where the chart has become vertical. Have fun keeping up with
> that.
 I seriously doubt any one system is going to need to record all that,
 after all, a site is are only going to record their "protected realm"
 A.K.A network of users, partners or known senders just like its
 currently done without sweating it. To assume a single system is
 going to need to record 228,848 billion of anything, well, is very
 ambitious for any single organization.

Doubts about managing each source within this space using CIDR lists is shared.

The term "protected realm" describes inbound MTAs associated with designated Kerberos services. Kerberos is likely to be an attacked service. As such it should be offered from distributed and robust networks, perhaps by third-parties. This service should include intra-realm communications to indicate which domains were offered tickets. This information could selectively open firewalls protecting services within the vast IPv6 environment.

> At the smaller /48 prefixes, 538, 474, 403, 271, and 270 million
> announcements are in Germany, Japan, rest of EU, Australia, and
> Korea respectively. Even so, all /48s represent just .000067% of
> the entire announced space.

 The large spectrum of IPv6 is well understood, but IMV, no single
 system is going to need to record anything close to these sizes,
 unless of course, your company is planning to take over the world.

Hardly. Just guessing, it seems growth will top out at 1.4 trillion (a million million) /64 equivalent prefixes. This represents a dramatic increase from 3.8 billion, especially since practices used to dismiss a sizable portion of IPv4 can not apply. Ignoring an inability to reduce the monitored space, 370,000 to 1 compression would be required to utilize resources currently available.

> Placing your inbound servers into a "protected realm" says you wish
> to establish a robust method for accepting messages from legitimate
> domains that you'll take steps to protect.
 Lets assume your I-D proposes something really fantastic - that it
 can have a high payoff and impact to lower spam.

The goal is to permit a method for defending services to ensure desired exchanges. You seem to suggest this would be your approach, but permissions would be referenced by domain rather than by IP address. Domain names should be easier to manage and can apply even when confronting LSNs.

 What happens to the other AUTH methods? Do we enforce KERBEROS only

The use of Kerberos based upon domain certificates is envisioned to represent a robust lightweight method to supplant reliance upon source IP addresses. This might be used only where needed, and might eventually become the norm. Either way, acceptance is still determined by inbound MTAs: either based upon source IP address or verified domain name. Kerberos simply affords an efficient method for the added validation that perhaps happens every N hours per source.

 My concern is the idea that SMTP systems will no longer need to
 accept mail from non-authenticated senders for local users and to
 move into a mode where all senders are (Kerberos) authenticated. In
 other words, the Public Port SMTP network will no longer be public.

That is not the change envisioned. This is to ensure desired exchanges are able to occur using manageable data-sets.

 If enforcement is not mandated, then why would a sender use it? What
 benefits do they get over others that using something else? That is
 something I would like to know in your I-D.

Again, the protections offered directly benefit senders. It affords a robust and lightweight basis in which exchanges can be accepted. The enhanced name based source information directly benefits senders that might otherwise contend with recipients suffering from resource constraints.


<Prev in Thread] Current Thread [Next in Thread>