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

--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> 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.

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.

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.  

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.

     john



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf