Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jul 6, 2007, at 1:52 PM, John C Klensin wrote:

--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
<dotis@xxxxxxxxxxxxxx> wrote:

...
How will SMTP servers vet sources of inbound messages within an IPv6 environment? Virtually every grain of sand can obtain a "new" IPv6 address. An IPv6 address may traverse any number of translation points as well.

This complex topology spells the end of SMTP in its current form. Perhaps SMTP could depend upon SMTP Client names or change into a type of URI based notification process, where messages are held by an HTTP server. The URI of the HTTP server might then replace reliance upon SMTP Client IP address reputation. SMTP represents just one protocol heavily dependent upon IPv4.

Doug, I think you are conflating two problems. There is running code (and extensive history) to demonstrate your conclusion is not correct; the other issue may indicate that some of the things that are now under development in the IETF are wrong-headed and that they need to be rethought --now or later.

It is more a matter of remaining relevant. If not now, then later matters even less.

First, SMTP was designed to work in a multiple-network environment, with gateways and relays patching over differences far more significant than anything related to the different between IPv4 and IPv6. Sometimes it underwent smaller or larger transformations in those other network-transport environments (e.g., using much more batch-oriented envelope structures). But anyone old enough to have seen a message move from EARN to the Internet and possibly then back to BITNET or into FidoNet or UUCP-based mail has rather strong empirical evidence that a mere change of network protocols doesn't do much to SMTP. It is perhaps worth remembering that RFC 821 contains a good deal of text, some appendices, and miscellaneous dancing around the topic of SMTP over non-TCP services.

You are right about SMTP "working" across topologies. I setup UUCP for offices back when dedicated business lines were considered too expensive. I set up older messaging schemes for my customers while conducting a peripheral design business. This business demanded timely exchanges of schematics, wire-lists, PCB photo-plots, test- vectors, and firmware. When first learning of the Internet, it was costing more than $10 per one page fax to Japan. It sounded as if the Internet was some sneaky method to "steal" expensive telco services.

Low cost Internet services together with today's level of abuse has lead to unintended DDoS attacks. Defending against this unintended attack depends upon IP address history. When this history proves ineffectively at refusing traffic from previously noted bad actors, SMTP no longer "works". It has been an ongoing battle to ensure bad actors are unable to exploit easily obtained IP addresses. This includes addresses used by dial-up accounts, compromised residential systems, and even ISPs not enforcing adequate AUPs. Compromised residential systems makes discerning the last category difficult, and perhaps soon abandoned as yet another casualty of faltering security.

On the other hand, any authentication, authorization, or validation technique that depends either specifically on IPv4 addresses or on some sort of end-to-end connection between the final delivery MTA (or MUA after it) and Submission MTA (or earlier) is going to be in a certain amount of trouble: from IPv6, from long relay chains, from long-delay networks, and so on. Obviously some of the proposed mechanisms in that class are much more sensitive to network variations (or, in the worst cases, any situation in which there is not a single connection between the MSA and the delivery server) and maybe the IETF should be looking harder at those characteristics before publishing or standardizing them.

Depending upon DNS to migrate protocol behavior is one concern. Wildcard records in DNS can increase the amplifications of some "intentional" DDoS attacks. To support SMTP, some servers will issue a long series of "scripted" DNS transactions which might have been dictated by bad actors (as if the goal was to taint and/or kill DNS). At least PNRP does not depend upon DNS. What will the IETF offer as an alternative to this proprietary name resolution protocol?

But the oldest sender-authentication and message integrity mechanisms of all don't depend on such endpoint connections over a single network technology: I, and I imagine many others, have had mailboxes on and off for 20-odd years that will not accept any traffic that does not arrive with a digital signature over the content that can be verified by software in the delivery (receiving) system and with requirements on the signed content, such as sequence numbers or time stamps, to prevent replay attacks. Such approaches either require a strong PKI or secure out- of-band transmission of secret keys, don't scale, or both, but those aren't SMTP problems.

An inability to validate an SMTP client name, or the remaining provisions permitting A record server discovery makes SMTP much harder to defend within complex topologies. These are general weaknesses created by SMTP that are unrelated to cryptographic strategies.

If SMTP were used to only exchange URIs (as a public version of a BURL extension), then there would be no need for SMTP authentication. HTTP certificates scale and are already cached by the OS. Atlas, proprietary interfaces within HTTP are also nearly impossible to defend. Another area where standardization has failed.

The cryptographic strategy used by DKIM does not offer a means to correlate signing domains with SMTP client domains transmitting to a public server. An inability of domains to authorize signing domains eliminates what might have been a reasonable approach for coping with possible replay abuse. In addition, transparent authorizations of signing domains using CNAMES or DNS sub-delegation makes DNS less robust by increasing server dependence. Importantly, transparent authorization will not provide any anti-replay abuse strategy. DKIM may then devolve into a key-per-user as a feckless anti-replay strategy. Excessive use of short lived and large cryptographic key RRs may also provide another cause for DNS to falter. Never mind the follow-on domain transversal or DNS wildcard policy schemes.

DNS has several weakness by today's standards, which do not lend themselves to easy or rapid correction. What happens when SMTP's awkward defensive strategies result in a loss of confidence in a faltering DNS?

-Doug

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]