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

[Douglas Otis <[e-mail]>]

On 4/19/12 4:26 PM, Murray S. Kucherawy wrote:
> 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?]
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