Subject: [Asrg] Re: Documents for LMAP BOF

From: John Levine <[email-masked]>
Date: 7 Feb 2004 20:09:47 -0000

I've made up two draft documents for the BOF, since neither Yakov and I
will be going.

a) LMAP overview, heavily reworked from the version that Alan wrote a
while ago.  I took out all of the comparisons to now abandoned documents
and added a discussion of the relative merits of using IP, HELO/EHLO,
return path, and message header addresses as verification keys, and why
LMAP uses the return path.

    http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt

b) a strawman "flexible sender verification" which basically squishes
DMP and a cut down version of RMX together, due to concerns from some
ISPs that want to do one lookup per domain, slurp up all the IPs for
that domain, and cache it, and other ISPs who want to do a simple DNSBL
style lookup for each message. 

      http://www.taugh.com/draft-levine-fsv-00.txt

Read fast, we have to sumit I-D's for Seoul by Monday.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Philip Miller <[email-masked]>
Date: Sat, 07 Feb 2004 22:22:14 -0500

>     http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt

Before starting in, one quick note: It would have been a lot easier to 
compare this mechanically (i.e. diff -u) to the -00 draft if you had used 
the same page-width as Alan did.

I have attached at the end of this message a diff of typo fixes.

In paragraph 1 of section 1.2, "Interpretation of LMAP Data", the range 
should cover complete reliance on the data published in LMAP (making 
accept/reject decisions solely on that basis) to complete ignorance 
(non-implementation on the recipient side or not using the data to influence 
the decision). I think the last sentence of that paragraph is entirely 
unnecessary.
Paragraph 2 is bluntly wrong. The intent of creating LMAP is that eventually 
it WILL be used to reject mail, because it is assumed to be forged. A 
comment like this belongs much later in the document, in a deployment 
considerations section.

In section 2.2.1, "IP Address", paragraph 2, I disagree with equating MTA 
Mark and LMAP. By design, they address different issues. MTA Mark addresses 
usage that providers don't like and is for the use of IP-space owners. LMAP 
addresses domain name abuse, and is for the owners of individual domain 
names. Although the intersection between those 2 sets is large (all ISPs, 
effectively), they are not equivalent.
OTOH, if your intent is really to generalize the concept embodied by LMAP, 
that runs contradictory to your email, which reads "... and why LMAP uses 
the return path." I have no objection to the generalization, but pick one, 
please.

I don't like how the comparison section phrases LMAP as a modification to 
RFC 2821. I suspect that such wording will raise a lot of unnecessary 
resistance to LMAP for no particular reason. I interpreted that part of RFC 
2821 to mean that recipient MTAs should not reject mail on the basis of the 
the HELO name not resolving to the connecting IP or the connecting IP not 
reverse-resolving to the HELO name. Following this interpretation, LMAP 
suggests neither, and thus is no modification to 2821, only an application 
of the liberties of "local policy"-based rejections.

As I look that the rest of 2.2.*, I notice that 2.2.1 is excessively chatty. 
Most of that should be in 2.2.5, "Comparison"

2.2.5, last paragraph: DATA payload headers are not particularly useful for 
LMAP verification, because there are frequent enough circumstances in which 
they will not verify for valid mail. They're also even more prone to RFC 
2821 non-compliance than HELO and return path are.

None of 2.3 belongs in the problem statement and scope section. LMAP does 
not address a problem in the DNS. Perhaps 2.3 should have been 3.1, and 
titled "Reliance on DNS". There should be a big reference to the "Security 
Considerations" section below in that, rather than spreading out such 
discussion.
The text in 2.3.1, "DNS Poisoning", has nothing to do with DNS poisoning 
attacks. Have a look at <http://www.securityfocus.com/guest/17905>

The section headers under 3, "Common Concerns with LMAP", are ambiguous. In 
reading carefully, it's clear that the section headers are the summary 
responses, but it may be clearer if they were the common concerns 
themselves, in quotes.
E.g.:
"3.1 LMAP Changes the end to end nature of the Internet"
"3.2 Roaming users are harmed by LMAP"
etc.

3.3, on Relaying and Forwarding, has more hand-waving than most of the rest 
of this document.
First off, there are 2 separate circumstances to be dealt with. They may 
have the same solution, but they should be described separately.
Here's how I would define them:
1. Relaying is a service provided to senders in which the relaying domain
agrees to deliver the sender's messages outside the relay's and sender's
domains.
In the relaying case, sender-rewriting is perfectly acceptable, as it means 
there is another party who is at least as responsible for the message as the 
sender, and is willing to accept that accountability. How the rewriting is 
done and ensuring that bounces, DSNs, and the like get through is all a 
matter of local policy and agreement.
2. Forwarding is a service provided to recipients in which the forwarding
domain agrees to deliver messages addressed to one mailbox to another mailbox.
The forwarding case is where the hand-waving comes in. Sender-rewriting is 
undesirable here. It means that the intermediary recipient is essentially 
forced to present themselves as accountable for a message that they have no 
connection to. It also present a heavy burden on many users who use 
something like pobox.com or ieee.org to forward to an ISP account where they 
have no control over any whitelisting.
Regardless of the merits and usability of various sender-rewriting schemes, 
there is massive potential for bad security and privacy without a lot of 
implementation consideration.
Basically, I believe that we need to shift gears from practically mandating 
sender-rewriting to making it clear that this is an open problem. This is 
somewhere that I think general IETF input would be very useful.

3.4. Kiosks, etc., is somewhat glib about this issue. I've recently been 
involved in discussions elsewhere on the major issues surrounding this. 
There are a few problems and solutions. Again, I don't think recommending 
this solution straight-off is the right way to handle it when we're putting 
this before a large group of people who would most likely make very valuable 
contributions to the discourse if it's clear that there's something to discuss.

If all of section 4 could be put in a table on a website somewhere, to make 
it easier to digest, that may be useful.

The note on DNS reliance should mostly fall under Security Considerations, 
as noted above.

The text acknowledging previous contributors has been removed.

>       http://www.taugh.com/draft-levine-fsv-00.txt

I will concur with Phill in that I don't think we need another rehash of 
these ideas. At any rate, if we submit the discussion document for 
consideration by the IETF, the implementation will be heavily discussed in 
that realm anyway. There's no point in muddying the waters on this point, 
and I think FSV does just that.

Philip Miller
--- draft-irtf-asrg-lmap-discussion-01.txt	2004-02-07 21:25:37.000000000 -0500
+++ draft-irtf-asrg-lmap-discussion-02.txt	2004-02-07 21:31:36.000000000 -0500
@@ -170,7 +170,7 @@
    a recipient would choose to accept that non-consensual mes-
    sage.
 
-   The method of eastablishing whether an IP address can send
+   The method of establishing whether an IP address can send
    messages for a domain is similar to the usage of Dialup User
    Lists (DUL) [ref: MAPS DUL].  With those methods, a network
    provider publishes a list of IP addresses which have been as-
@@ -276,7 +276,7 @@
      to pretend not to be a sender on a recipient's blacklist.
 
    +o In account fraud, also known as ``phishing'', a sender poses
-     as a person or organization with whom the receipient has a
+     as a person or organization with whom the recipient has a
      business relationship, or would like to have a business re-
      lationship.  The sender does so in order to trick the recip-
      ient into revealing personal information that the sender can
@@ -392,7 +392,7 @@
    that the host at the connecting IP is authorized to use the
    domain name it is offering.  Like IP validation, HELO/EHLO
    validation doesn't provide a contact e-mail address.  The HE-
-   LO/EHLO address shold be the host's name, such as MAIL.EXAM-
+   LO/EHLO address should be the host's name, such as MAIL.EXAM-
    PLE.COM, even if the mail it sends all has addresses in the
    domain EXAMPLE.COM.  Although the address Postmaster@EXAM-
    PLE.COM would exist, the address [email-masked]
@@ -403,7 +403,7 @@
    mail since few hosts accept mail to domain literal addresses.
    RFC 2821 permits the SMTP server to validate a domain address
    provided to EHLO or HELO by doing a DNS lookup to see if the
-   IP address matxhes, but does not permit the server to reject
+   IP address matches, but does not permit the server to reject
    mail if the validation fails.  HELO/EHLO-based LMAP would mod-
    ify RFC2821 by allowing the server to reject mail based on HE-
    LO/EHLO validation failure.
@@ -429,7 +429,7 @@

    Although any or all of these items could be used for message
-   validation, the LMAP propoals use the return path as a compro-
+   validation, the LMAP proposals use the return path as a compro-
    mise between the best quality data and efficiency of opera-
    tion.  A verified return path, unlike IP or HELO/EHLO data, is
    very likely to provide a specific responsible address and re-
@@ -530,7 +530,7 @@
 
    Another concern raised about LMAP is that it will negatively
    affect roaming users, that is, users not connected to their
-   usual or home networ.  The main concern of roaming users is
+   usual or home network.  The main concern of roaming users is
    that the deployment of LMAP will break the "end to end" nature
    of the Internet.
 
@@ -585,7 +585,7 @@
 
    Roaming users may update LMAP information for their domain
    through Dynamic DNS (DDNS).  Any messages they send will then
-   pass LMAP criteries, subject to DNS propagation delays.
+   pass LMAP criteria, subject to DNS propagation delays.
 
    Roaming users can also publish a policy though LMAP that any
    IP address on the Internet is permitted to claim association
@@ -700,7 +700,7 @@
 
    Each of these proposals is a work in progress, hence the read-
    er must refer to the latest defining document for each to
-   learn the eaxct details of each.  These comparisons are not
+   learn the exact details of each.  These comparisons are not
    intended to recommend one proposal over another, but rather to
    highlight the differences among them.
 
@@ -877,8 +877,8 @@
 
    Publication of LMAP information results in a readily available
    list of IP addresses of hosts authorized to send messages as-
-   sociated with a domain.  These lists yeild information about
-   the network structure, andbusiness relationships, and presents
+   sociated with a domain.  These lists yield information about
+   the network structure, and business relationships, and presents
    hostile parties with a list of targets to attempt to compro-
    mise.

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 08 Feb 2004 13:23:20 +0000

> have no control over any whitelisting.

I'm not sure from which point of view you judge sender-rewriting
undesirable. It's simply not true that the forwarder has "no connection to"
the messages they forward. The forwarder is not part of, or contracted
with, the recipent ISP, they're as responsible for the messages they submit
as is any other external system. I guess there is added burden for some of
the players here, but they're at liberty not to implement, and suffer some
degradation to their service. This would be an issue for a user who choses
to use a forwarder in an unfriendly environment, and a cost issue for the
forwarder.

I don't see how it's really fair that I should be able to provide services
(and make a profit) in the middle, without taking on some responsibilities
there also.

--

---

From: Philip Miller <[email-masked]>
Date: Sun, 08 Feb 2004 20:58:53 -0500

Jon Kyme wrote:
>> 2. Forwarding is a service provided to recipients in which the
>> forwarding domain agrees to deliver messages addressed to one mailbox
>> to another mailbox.
>> The forwarding case is where the hand-waving comes in. Sender-rewriting
>> is undesirable here. It means that the intermediary recipient is
>> essentially forced to present themselves as accountable for a message
>> that they have no connection to. It also present a heavy burden on many
>> users who use something like pobox.com or ieee.org to forward to an ISP
>> account where they have no control over any whitelisting.
> 

How about we look at a case where the forwarder has no profit, just cost: 
debian.org. Many debian.org users use their addresses as a general purpose 
address, with the intention that they will always have it, to forward 
wherever they go. Thus, they receive and forward mail coming from all over, 
none of which a 3rd party should see them as responsible for. In many 
particular cases, that 3rd party is a large ISP corporation that has no 
profit motive to let end-users selectively disable filtering of some of 
their mail. Thus, debian.org, ostensibly an agent of the recipient, is 
forced to bear a cost (taking responsibility for the message in the eyes of 
the recipient ISP) in place of the sender.

Perhaps what we need is some standardized way for the recipient/forwarding 
user to authorize the message in advance of any filtering. Unfortunately, 
that probably won't be effective in this case unless we got an ESMTP 
extension designed for it, because ISPs want to filter as early as possible 
in the transaction.

Philip Miller

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 09 Feb 2004 10:14:50 +0000

> wherever they go. 

OK, debian.org are providing the "appearance" of a mailbox for no charge.
Jolly good. Well done.

>In many 

Indeed, that's the point. debian.org *are* sending this mail to
isp.example. They're doing this as the agent of a person who is a customer
of isp.example They are not doing this *for* isp.example, they're doing
this *to* isp.example

isp.example hold debian.org responsible for sending it. What's wrong with
that?

If isp.example users can't modulate the filtering behaviour to pass-thru
the debian.org routed stuff and some LMAP-thing is active - this will be a
hostile environment for forwarding. debian.org have a number of
alternatives:

1. do the rewriting (and accept some implied responsibility?) 
2. refuse to rewrite and get blocked by systems which don't like the look
of mail from example.com routed via debian.org
3. Provide a real mailbox, POP / IMAP.

> extension designed for it, because ISPs want to filter as early as

Ideally, a system running LMAP-thing should give users the ability to
configure it in such a way as not to be forwarding-hostile. If there's no
"profit-motive" for supporting this, it suggests that customer demand is
too small.

I'm very much in favour of some standard for configuring filtering at the
ISP. However, I can't see how one could make this a pre-requisite for LMAP
deployment.

It seems possible that widespread adoption of LMAP-like systems could
increase costs for forwarders. I don't believe there's a rule which says
that the forwarders p.o.v. is more significant than the receiving ISP's.

The feature that allows debian.org to forward transparently has costs.
Spome of these costs are currently borne by mom&pop.example.com when their
little mail server chokes on 50k bounces an hour from yahoo for spam they
didn't send.

The costs of spam at isp.example are passed onto the user, they have a
business model which supports this. If the forwarder doesn't have such a
business, they may have to reconsider the services they offer.

Omelette v. Eggs, I suppose, or, better, TANSTAAFL.

--

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 09 Feb 2004 07:04:15 -0500

Philip Miller <[email-masked]> wrote:
> it WILL be used to reject mail, because it is assumed to be forged.

  Absolutely not.

  The intent is to publish information which lets the recipient MTA
make that decision.  This is a very different statement of intent than
what you wrote.

  I expect that *many* implementors of LMAP will choose to reject
non-compliant messages, but it would be inappropriate for anyone to
say that those MTA's are *required* to reject mail based on LMAP.

> of the liberties of "local policy"-based rejections.

  I agree.  The text in the -00 draft tried to explain this
distinction.

  The -01 document says: (2.2.5, page 7)

>> HELO/EHLO-based LMAP would
>>    modify RFC2821 by allowing the server to reject mail based on
>>    HELO/EHLO validation failure.

  I disagree completely.  The HELO/EHLO validation in RFC2821 is about
looking up the reverse IP of the originating MTA, and seeing if the
name returned is the same as the HELO/EHLO field.  LMAP does something
completely different, it looks up in the domain of the HELO/EHLO
field, to see if the originating IP is permitted to claim association
with that domain.

  Alan DeKok.

---

From: Philip Miller <[email-masked]>
Date: Mon, 09 Feb 2004 18:40:13 -0500

> say that those MTA's are *required* to reject mail based on LMAP.

Perhaps I wasn't clear. I didn't mean that recipient MTAs *MUST* 55x 
LMAP-violating mail, I meant that they would be explicitly *allowed* to, 
which is contrary to the wording in the most recent draft.

> field, to see if the originating IP is permitted to claim association

Glad we're agreed on this point.

Philip Miller

---

From: Philip Miller <[email-masked]>
Date: Mon, 09 Feb 2004 18:44:41 -0500

Jon Kyme wrote:
>> In many particular cases, that 3rd party is a large ISP corporation
>> that has no profit motive to let end-users selectively disable
>> filtering of some of their mail. Thus, debian.org, ostensibly an agent
>> of the recipient, is forced to bear a cost (taking responsibility for
>> the message in the eyes of the recipient ISP) in place of the sender.
> 
>> Perhaps what we need is some standardized way for the 
>> recipient/forwarding user to authorize the message in advance of any
>> filtering. Unfortunately, that probably won't be effective in this case
>> unless we got an ESMTP extension designed for it, because ISPs want to
>> filter as early as possible in the transaction.
> 

Perhaps it's time to suggest a different approach for forwarders.

Since forwarders are clearly trusted by the user, we should make it possible 
for the forwarder to deliver directly to the user's inbox, rather than 
transferring messages like any other mailer. What if the user had the 
forwarding system connect to his IMAP host and inject the message there? The 
biggest problem I see with this is that it breaks multiple forwarding and 
intermediate filtering (viruses, procmail/popfile sorting, etc.). If it 
injected to a special folder, that would be solved, too. Now we just need a 
standard way to carry this out for forwarders to implement.

Philip Miller

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 10 Feb 2004 10:01:50 -0800

Just wanted to provide some more info on the seriousness of IP hacking, 
WRT LMAP.

<http://www.dnsbl.au.sorbs.net/Zombie-FAQ.html> (which is based on 
<http://www.completewhois.com/hijacked/hijacked_qa.htm>) provides an 
intro to the issue.  <http://www.completewhois.com/hijacked/index.htm>, 
and other pages at that site make it clear that this is currently a 
serious problem. In the same way that ISPs knowingly allow spammers to 
reside on their networks, they will increasingly knowingly allow IP 
Hijackers to connect to their networks.

S-BGP is mentioned as an infeasible solution: "S-BGP can solve the 
problem but will require upgrades to the core Internet infrastructure as 
it requires a lot more memory for routers ... [and more] CPU power or 
specific hardware for cryptography. Because of these necessary hardware 
upgrade and serious investment in new hardware that would be necessary, 
S-BGP has not gone beyond theoretical work so far. "

SysAdmins would be wise to ensure that their upstream's IP space is 
properly registered with their RIRs to a current email address, and that 
more than just email security is used to authorize updates, and finally 
to refuse to route through their network IP blocks that are known to 
have been hijacked, and have their upstreams do so.

Because this security problem is likely to be ongoing, it should be 
addressed in draft-irtf-asrg-lmap-discussion.
Do we have two competing versions of the latest, BTW?
<http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt> 
,
<http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt ? The 00 is 
newer than the 01> .

I agree with PHB:
 > This is something the IAB should consider as a matter of urgency.

Anyway, here an attempt to address this.
I propose a section 2.4 that reads something like:

2.4 BGP based attacks

All versions of LMAP rely on the security of TCP to assure that a 
message that appears to be sent from an IP address is actually from 
equipment of the owner/renter of that IP address.  But IPs can be and 
are hijacked - hijackers announce BGP routes to the IP space they wish 
to steal, and much of the Internet starts routing packets for that IP 
space to them [ref to 
http://www.completewhois.com/hijacked/hijacked_qa.htm].  If an IP in IP 
space authorized by LMAP records is hijacked, the hijacker can send spam 
from that IP and LMAP will make it appear to be authorized until the 
domain admin can react and update LMAP records or regain control over 
the stolen IP space. 
 In the same way that Tier 1 ISPs knowingly allow spammers to reside on 
their networks, it it likely that they will increasingly knowingly allow 
IP Hijackers to connect to their networks. The fact that most hijacked 
IP space is unused somewhat mitigates the risk this poses, as such IPs 
are less likely to be authorized by LMAP records, as does the fact that 
such IP space is often quickly blacklisted [ref to 
http://www.dnsbl.au.sorbs.net/Zombie-FAQ.html].

One more thing - what's with my name being removed from the credits? 
Contributors need to be listed. I and others contributed and are in
<http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf-asrg-lmap-discussion-00.txt>, 
but not in the later versions; you can grab my contact info from 
<http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-00.txt> if 
you want to add all that.