On 4/19/12 4:26 PM, Murray S. Kucherawy wrote:
Comments inline.
From: [email protected] [mailto:[email protected]] On Behalf Of Steve
Atkins
Sent: Thursday, April 19, 2012 11:50 AM
To: [email protected]
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
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
