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

["Murray S. Kucherawy" <[e-mail]>]

Comments inline.

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

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.

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

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.

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

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?

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

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

[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