Subject: [marf] Reviewers for draft-kucherawy-marf-source-ports

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 18:16:33 +0000

Hello MARF,

The above draft was mentioned during the (brief) meeting in Paris.  It is a simple document that registers with IANA a RECOMMENDED field for ARF reports to include the port number from which the abusive action came.  This is encouraged practice in the IETF these days, as you can see from the document about logging that this one references.

It was decided in Paris to process it outside of MARF so that we could continue the process of winding down, since the draft is so simple.  Still, we need a few reviewers for the record.  Could we get a couple of volunteers?

Here's the datatracker link: https://datatracker.ietf.org/doc/draft-kucherawy-marf-source-ports/

It's five pages, about two of which are typical RFC boilerplate.  Truly a quick read.

If you've read it and agree with it, you can reply here and just say so.  Of course, if you have comments, those are also welcome.

Thanks,
-MSK

---

From: Steve Atkins <[email-masked]>
Date: Thu, 19 Apr 2012 11:49:41 -0700

On Apr 19, 2012, at 11:16 AM, Murray S. Kucherawy wrote:

> Here’s the datatracker link: https://datatracker.ietf.org/doc/draft-kucherawy-marf-source-ports/
>  
> It’s five pages, about two of which are typical RFC boilerplate.  Truly a quick read.
>  
> If you’ve read it and agree with it, you can reply here and just say so.  Of course, if you have comments, those are also welcome.

It looks reasonable at first glance. But I have some comments.

MARF is intended for reporting sightings of email. This extension is intended to make reports of traffic from behind NATs able to differentiate between users behind a NAT. That implies that it's expected for legitimate email to be sent from behind a shared NAT. I wouldn't expect to see that in the wild, certainly not at a provider that's well enough set up that they're accepting ARF reports and keeping detailed access logs and so on - rather I'd expect that mail to be going through an authenticated smarthost, and no non-authenticated SMTP traffic being emitted from the NAT itself.

Do carrier-grade NATs in general use really log connections in enough detail that the source port is adequate to identify the user of the NAT? AIUI many of them cycle source ports almost immediately, with no persistent relationship with the user, so they'd need to persistently log every TCP connection every user made for this to be useful data.

For source port to be useful to the sender, even assuming they have NAT connection logs, the timestamp of the report is going to be much more critical than for previous ARF usage. Dynamically assigned IP addresses tend to last hours, dynamically assigned NAT mappings just seconds. We don't mention anything about timestamps in [ARF], other than to say it should be in RFC5322 format. Do we need to stress the need for NTP-level timing accuracy at every host involved, or is the mention of that in [LOG] enough?

[LOG] recommends UTC timestamps for everything. Do we want to encourage that for ARF too?

What about ident?

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 15:43:51 -0400

> [LOG] recommends UTC timestamps for everything. Do we want to encourage that

For interoperability purposes, it's sufficient if the TZ is recorded, I think 
that's sufficient.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 23:26:20 +0000

Comments inline.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Thursday, April 19, 2012 11:50 AM
To: [email-masked]
Subject: Re: [marf] Reviewers for draft-kucherawy-marf-source-ports

[MSK: That's probably generally true, but I'd imagine it's not universally true.  For the cases where it's not, the data reported by this extension header field might prove useful.]

[MSK: This is what Section 3 of [LOG] advocates.  We're simply matching what they're doing.]

[MSK: We could certainly repeat that advice, or stress the importance of that part of [LOG].]

[MSK: I agree with Scott; email date format captures enough information to convert to UTC if needed.  We could say that the report generator MAY convert the ARF date field, whatever it's called (can't recall), in UTC to enable quicker log correlation.]

What about ident?

[MSK: Does anyone still use that?]

Cheers,
  Steve

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2012 23:32:51 -0000

Remember that we didn't make up this port logging stuff.  It's in RFC 6302.

>That implies that it's expected for legitimate email to be sent from behind a shared
>NAT. I wouldn't expect to see that in the wild

I believe that it's already happening in parts of Asia.  Also, I
expect there are plenty of places where mail leaks out from a web farm
or something else behind a NAT that's not primarily a mail server.

>Do carrier-grade NATs in general use really log connections in enough detail that the
>source port is adequate to identify the user of the NAT?

Combined with the time stamp, it should be.  I agree that accurate time stamps are
important, but they already are for tracking down stuff on busy systems.

>What about ident?

It's hard to see how that would work without making NAT an order of
magnitude grosser than it is now, doing DPI on the incoming stream on
port 113 to figure out which host behind the NAT to route it to.  Or did
you mean that the NAT would handle port 113 requests itself?

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Thu, 19 Apr 2012 17:01:20 -0700

On Apr 19, 2012, at 4:26 PM, Murray S. Kucherawy wrote:

> [MSK: That’s probably generally true, but I’d imagine it’s not universally true.  For the cases where it’s not, the data reported by this extension header field might prove useful.]

I'm not sure that [LOG] *as applied to email* has value in the real world. Sure, a mix of spam and legitimate mail might leak out from a NAT, but the fix for that is to not allow port 25 outbound from the NAT and route it to a smarthost (where it can be filtered, throttled and have correct Received headers to identify the user added) instead.

It's reasonably harmless to add this information to ARF reports, but to standardize it implies that allowing outbound port 25 from a carrier-grade NAT is acceptable practice, which goes against the "don't let end-users or dynamically assigned users send mail directly to receiver MXes" and "don't allow port 25 through a NAT" principles we've been pushing for a while.

http://www.spamhaus.org/faq/section/Spamhaus%20XBL#37
http://cbl.abuseat.org/nat.html

http://www.ic.gc.ca/eic/site/ecic-ceac.nsf/vwapj/Companion_Document.pdf/$file/Companion_Document.pdf
http://www.maawg.org/sites/maawg/files/news/MAAWG_Port25rec0511.pdf

> [MSK: Does anyone still use that?]

Sure. I'm not suggesting people use it, but this proposal is a less reliable, less privacy-friendly, replacement for ident so I thought I'd at least mention it.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Apr 2012 00:08:26 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Thursday, April 19, 2012 5:01 PM
To: [email-masked]
Subject: Re: [marf] Reviewers for draft-kucherawy-marf-source-ports

[MSK: I don't think publishing this extension amounts to an endorsement of allowing outbound port 25 from within a CGN.  Why is ARF the right place to make that stand?  For cases where such is allowed, the data exchange is desired.  Preventing ARF from doing it won't change ISP policies.]

What about ident?

[MSK: I don't think ident has enough current support to make it a viable alternative.  How is adding ports to ARF reports a privacy concern?]

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Thu, 19 Apr 2012 17:24:32 -0700

On Apr 19, 2012, at 5:08 PM, Murray S. Kucherawy wrote:

> [MSK: I don’t think publishing this extension amounts to an endorsement of allowing outbound port 25 from within a CGN.  Why is ARF the right place to make that stand?  For cases where such is allowed, the data exchange is desired.  Preventing ARF from doing it won’t change ISP policies.]

I think it's reasonably harmless to document how to do it in ARF. 

I don't think it will be of any value to report recipients or senders (for the reasons above) but that's no reason not to standardize it.

> [MSK: I don’t think ident has enough current support to make it a viable alternative. 

I tend to agree - but this is such a direct replacement for ident I thought I'd mention it.

> How is adding ports to ARF reports a privacy concern?]

It's not. The privacy issue is in [LOG], not here.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 23:51:27 -0400

On Thursday, April 19, 2012 05:24:32 PM Steve Atkins wrote:
...
> I don't think it will be of any value to report recipients or senders (for
> the reasons above) but that's no reason not to standardize it.
...

Sure it is.  Additional complexity doesn't come for free, so it shouldn't be 
accepted without reason.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2012 12:39:09 -0000

>Sure it is.  Additional complexity doesn't come for free, so it shouldn't be 

Having added Source-Port to my reporting scripts yesterday, I can say that
the additional complexity involved is quite small.

Remember that this draft is just implementing the logging advice in
RFC 6302, whose authors work at Juniper, Yahoo, Facebook, and AT&T.  I
would assume that their employers wouldn't have given them time to
work on it if they didn't think it would be of some value.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 20 Apr 2012 08:45:11 -0700

> work on it if they didn't think it would be of some value.

Email through dynamic NAT is not the same as HTTP through dynamic
NAT, though.

Source port only provides useful information to the report recipient if
there are at least two SMTP sessions from the NAT to the same MX
initiated (SYN) within a second or two of each other, and one of those
SMTP sessions is a cause for complaints and one of those SMTP
sessions is legitimate email. And the mail that's causing complaints
needs to be "direct-to-MX" bot-style spoor, most likely, or there'll
be plenty of information in the Received headers of the mail that's
being complained about to identify the customer more easily than
going through NAT logs.

Adding source port information to an ARF report only benefits the
sender of the report if all the above are true, and the report recipient
is going to expend the effort to grovel through their NAT logs to identify
the rooted machine that's spewing spam, despite them not caring about
emitting spam to the extent of blocking port 25 outbound from their
NAT. 

(I deal with a lot of customers who dynamically assign their
customers IP addresses, and the effort involved in dealing with
that data as part of complaint handling is significant, and it's painful
enough that they cannot do it in anything close to real time. NAT
logs are going to be much larger, and much more dynamic. Groveling
through them is going to take *significant* effort.)

When you combine the technical and the social, I don't think adding
the source port is going to change the result of the ARF report in a
significant number of cases.

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Apr 2012 11:24:46 -0700

> [MSK: Does anyone still use that?]
Dear Murray,

LSNs or CGNs headed in the direction of using NAT-PMP.

See http://miniupnp.free.fr/nat-pmp.html for a general description.
http://tools.ietf.org/html/draft-cheshire-nat-pmp-03
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05
Note: REQ-13: A CGN SHOULD NOT log destination addresses or ports.

Also see:
http://tools.ietf.org/html/draft-ietf-pcp-base-24#section-11.5

The significant difference from UPnP is NAT-PMP scheme is resource 
driven rather than being based upon uninformed (scanning) requests.  In 
addition, resources can be reassigned as needed.  Both of these features 
better suit LSN or CGN efforts, especially when port resources are being 
shared across perhaps hundreds of separately sourced transactions.  
Also, such use is likely to be the fault of recipients failing to 
provide IPv6 connectivity causing access providers to employ a large 
scale NAT solution.   NAT-PMP is able to inform the client of both the 
translated port mapping as well as what is the current external IPv4 
address.  What was missing was a translation to the current IPv4 to IPv6 
translation.  The purpose of NAT-PMP was to not be limited by static 
assignments. Source assessments require mapping connections in real-time 
via PCP.  As such, adding ports rather than requiring real-time mapping 
would be the wrong approach.  No one will be retaining the logs as they 
will be far too dynamic.

Regards,
Douglas Otis