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

[Steve Atkins <[e-mail]>]

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

> 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.

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