ISE write-up for: draft-daveor-cgn-logging-02
Abstract:
"The use of large-scale IP address sharing technologies (commonly
known as "Carrier-Grade NAT" and "A+P") presents a challenge for law
enforcement agencies due to the fact that incoming source port
information is not routinely logged by Internet-facing servers. The
absence of this information means that it is becoming increasingly
difficult for law enforcement agencies to identify suspects in
criminal activity online. This document considers the reasons why
source port information is not routinely logged by Internet-facing
servers and proposes some immediate-term actions that can be taken to
help improve the situation. A deployment maturity model has been
developed and a study of the support for logging incoming source port
information in common server software is also presented."
This draft has no requests for IANA.
It was reviewed for me by Joel Halpern, Mohamed Boucadair and Joel Jaegli.
The authors have responded to the changes suggested by the reviewers,
and also made the changes requested by the ISE.
- - - - - - -
Joel Halpern's review:
Very nice.
Rather than missing items I was aware of, the author provides a thorough set of
pointers to the CGN logging analysis and proposals, including some recent work
I had forgotten.
He then moves on from that and provides a clear report on an analysis of 16
open source server logging packages and the degree to which they meet the needs
he identifies.
The document includes a clear explanation of why the work was done, what the
issues are, and why a relevant reader should care.
Overall, I think it is a useful and relevant document for the series.
I do not have any comments for the author.
- - - - - - -
Mohamed Boucadair's review:
Review of draft-daveor-cgn-logging
1.1. Overall
First, I'm not against the publication of this document as an RFC.
Some modifications are required to be implemented. I hope the author
will make changes as appropriate.
1.2. Detailed Review
As I mentioned in my first e-mail, I'm already engaged with Dave in
reviewing his document. I already shared with him a first set of
comments, but Dave didn't release an updated version of the draft.
So, my comments are still pending.
Please refer to the attached file.
1.3. Clarify the Scope
Some work is still required to better focus on the main contribution
of the document compared to existing RFCs. In particular, I do
suggest that a clear "Scope" section is added to position this work
with regards to existing RFCs. The IETF conducted in the past an
important effort to increase awareness to issues related to address
sharing, including logging matters. Concretely, the IETF published
RFCs that contributed to:
1. Identify logging as an issue in address sharing: RFC 6269
2. Require address sharing to enable a logging function: RFC 6269
and RFC 6888
3. Identify a minimal set of information to be logged: RFC 6269,
RFC 6888, and RFC 6908
4. Identify and discuss trade-offs of solutions to achieve logging:
RFC 6269, RFC 6908
5. Specify means to optimize logging (port range allocation,
deterministic NAT): draft-ietf-softwire-stateless-
4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
RFC7422
6. Recommend servers to log source port: RFC 6302
7. An initial survey of servers supporting source port logging: RFC
7768
8. Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
logging, draft-ietf-behave-ipfix-nat-logging
9. Enable address sharing logging function by means of NETCONF:
draft-ietf-opsawg-nat-yang
10. CPU and memory issues: RFC 6908
Those aspects should be called out explicitly in draft-daveor-cgn-
logging.
1.4. How Another Yet RFC Will Increase Awareness?
The document should discuss, if possible, why another yet RFC will
increase awareness among the servers developers community.
1.5. The document is CGN-centric
The document seems to focus on the CGN case, while alternate address
sharing flavors are currently deployed by many operators. These
alternate solutions are called A+P (RFC 6346, RFC 7596, RFC 7597, RFC
7599, RFC 7753). The document should call out those.
1.6. Interference with Proxies and Load Balancer
The source IP address (and source port number) may not be preserved
in the original packet when traversing a CDN infrastructure or when
proxies and load-balancer are on-path. A logging server may not be
able to log to source IP address and port under such condition.
It would appropriate to add this issue to the document.
- - - - - - -
Joel Jaegli's review:
I reviewed this document at the request of the independant stream
editor. In general I think this is a reasonable take on subject matter
that the IETF would not ordinarily take on. Setting that problem aside,
which is the prerogative of the independent stream editor I have a few
thoughts.
While the document is largely focused in intermediate NAT infrastructure
and therefore at the problem of source address/port mapping it may well
be the case that destination IP address is also something that needs to
be exposed to the logging infrastructure. for example CDNs support multi
tenancy through SNI, so the absence of the destination address in the
logging stream may preclude you from identifying the destination IP in
the servers log stream. So that for example if you start from server
side logs which ip was used may well be an open question. (if you have
the middlebox logs logs first you may have enough information to find
the connection in the services logs).
this is relevant to for example:
https://www.bamsoftware.com/papers/fronting/
where the destination ip mapping may be orthagional to the information
logged in the upper layer.
so in for example
Previous work has already suggested as best practice the logging by
Internet-facing servers of source IP address, source port and exact
connection time [RFC6302 <https://tools.ietf.org/html/rfc6302>].
server probably has to collect/log the dest ip as well.
some nits
page 6
Clearly lack of support in server software is an insurmountable
technical obstacle for a server operator.
It's a technical obstacle. it's unlikely that it would be
insurmountable. Consider that one reason one ends up lossing access to
the source port is being behind an load balancer (l3/l4) that does
snat. in that case the actual source port used over the internet has
been transformed again so that it represents the source port on the load
balancer. logging the source port therefore would have to be done on the
SNAT prior to transformation.
page 10
6.4. Parallel Logging to a Connection Log
As noted in the comments on page 6 one reason that this information
might need to be collected in parallel is that the information is itself
available on the server producing the logs. load balancer's particularly
those that snat may have further limits on the scalability of their
logging giving they don't get to terminate connections and therefore
may be in the position of logging dos traffic.
By contrast L7 load balancers would oridinarily log for destinations
(for http) using x-forwarded-for or forwarded http exentsion, the later
includes an option for source port but the former does not.
- - - - - - -