Subject: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-requirements)

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 16:54:54 -0700

The current text in
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-03#section-4
implies that a CGN needs to log destinations.

As we all know, there are two significant drawbacks to destination 
logging:

  * if more than one user is visiting the same site, destination
    logging doesn't help distinguish between those users.  Source port
    logging does.  The corollary is that destination logging helps
    identify a user visiting an unpopular server when that unpopular
    server is not logging source port.
  * destination logging creates privacy issues.

To align draft-ietf-behave-lsn-requirements with RFC6302 ("Logging
Recommendations for Internet-Facing Servers"), should
draft-ietf-behave-lsn-requirements instead state that destination
logging SHOULD NOT be performed, and recommend that a CGN simply
do source port logging in anticipation of servers following 
RFC6302?

-d

---

From: ssenthil <[email-masked]>
Date: Thu, 13 Oct 2011 22:50:11 -0400

>     server is not logging source port.

The destination information logged in conjunction with the translated source
address/port information and original source address/port (or subscriber
identification) can uniquely identify a user behind the CGN even if there
are multiple users accessing the same destination.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Oct 2011 05:06:29 +0200 (CEST)

> are multiple users accessing the same destination.

If the server is logging source port then destination based logging isn't 
needed as far as I can see. If the server doesn't log source port, then 
destination based logging doesn't help for popular sites because they're 
going to be for the same IP/port anyway.

I support recommendation doing only source port logging, I am a huge fan 
of bulk port allocation and only logging these bindings and never log 
destination based. Logging destination based has both practical (huge log 
volume) and privacy implications.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Benson Schliesser <[email-masked]>
Date: Sun, 16 Oct 2011 15:50:44 -0500

> do source port logging in anticipation of servers following 

I don't think draft-ietf-behave-lsn-requirements should specify one way or the other.  I do think that it should discuss the topic in "MAY" terms, and give appropriate cautions.

Clearly, logging destination along with translated and original source address + port would reveal customer behavior in some detail.  Logging only the translated and original address + port would be adequate for law enforcement requests targeting specific historical transactions. Logging only destination (and nothing else, or decoupled from source logging) might be informative from a demographic perspective, but has a smaller privacy impact.

While I personally don't find the privacy implications very appealing, I know that this kind of intelligence is already gathered by some ISPs. (With DPI tools etc.)  There may be law enforcement and/or business reasons that they want this, and making the IETF document take an opposition position would only cause problems - vendors will still produce what SP customers want, resulting in a situation where CGN products are frequently not compliant with this document.

Cheers,
-Benson

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Oct 2011 15:49:48 -0700

> -----Original Message-----
> From: Benson Schliesser [mailto:[email-masked]]
> Sent: Sunday, October 16, 2011 1:51 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] CGN Requirements: logging (draft-ietf-behave-lsn-
> requirements)
> 
> 
> I don't think draft-ietf-behave-lsn-requirements should specify one way
> or the other.  I do think that it should discuss the topic in "MAY"
> terms, and give appropriate cautions.
> 
> Clearly, logging destination along with translated and original source
> address + port would reveal customer behavior in some detail.  Logging
> only the translated and original address + port would be adequate for
> law enforcement requests targeting specific historical transactions.

It seems that is the core of the requirement created by IPv4 address
sharing, especially in light of RFC6302 (Logging Recommendations for 
Internet-Facing Servers).

> Logging only destination (and nothing else, or decoupled from source
> logging) might be informative from a demographic perspective, but has a
> smaller privacy impact.
> 
> While I personally don't find the privacy implications very appealing,
> I know that this kind of intelligence is already gathered by some ISPs.
> (With DPI tools etc.)  There may be law enforcement and/or business
> reasons that they want this, and making the IETF document take an
> opposition position would only cause problems - vendors will still
> produce what SP customers want, resulting in a situation where CGN
> products are frequently not compliant with this document.

Considering such a requirement exists in some places (today) without
CGN, the deployment of a CGN would not affect those network's requirements
to do destination logging -- they would still be required to log 
destination.  I don't want to conflate "logging destinations is needed 
in Country X" with "CGN requires logging destinations".

-d

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 18 Oct 2011 11:23:49 -0700

> Internet-Facing Servers).

Yes, and I agree that logging translated and original source address + port is something that might be a SHOULD or MUST requirement.

> in Country X" with "CGN requires logging destinations".

I agree, we should not conflate these topics. That's why the requirements document should avoid "SHOULD NOT" or "MUST NOT" language, with regard to destination logging.

Cheers,
-Benson

---

From: Olivier Vautrin <[email-masked]>
Date: Fri, 28 Oct 2011 17:44:27 -0700

What about the "bulk port allocation"? The draft is explaining in detail
the mechanism but do not give any recommendation. I think we should at
least have a "SHOULD" to support the bulk port allocation. It is difficult
to believe that in the future, service providers we will still log all the
sessions on a CGN device.

/Olivier

On 10/18/11 11:23 AM, "Benson Schliesser" <[email-masked]> wrote:

>Yes, and I agree that logging translated and original source address +
>port is something that might be a SHOULD or MUST requirement.
>
>I agree, we should not conflate these topics. That's why the requirements
>document should avoid "SHOULD NOT" or "MUST NOT" language, with regard to
>destination logging.
>
>Cheers,
>-Benson
>

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 28 Oct 2011 22:21:44 -0500

> sessions on a CGN device.

I tend to agree with your conclusion.  However, if we do per-connection allocation of ports, then there might be benefits to the CGN operator and users.  For instance, there might be improved security and more efficient utilization of CGN port resources.  Thus, an operator that doesn't care about logging might not want to use bulk port allocation.

My opinion is that if we say that a CGN "SHOULD" do bulk port allocation, then we should also say that it "MAY" do per-connection port allocation (based on the rationale I just described).  Thoughts on this?

Cheers,
-Benson

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 28 Oct 2011 22:20:43 -0700

> My opinion is that if we say that a CGN "SHOULD" do bulk port allocation, then we should also say that it "MAY" do per-connection port allocation (based on the rationale I just described).  Thought…

I would rather not see any recommendation here.  SHOULD is in fact a
very strong word in the IETF.  If something must be said, then we
should say both SHOULD be implemented for the operator to choose.

I have been operating a CGN probably longer than there has been the
term CGN without bulk port and i see no compelling reason to change.
In fact, we had an operational issue with a new CGN implementation
that was reserving ports and had a substantial issue load-balancing
bulk connections over CPU cores when bittorrent clients would request
thousands of connections from a single internal IP... resulting in bad
chunking effects.

Cameron

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 29 Oct 2011 10:38:01 +0200 (CEST)

On Fri, 28 Oct 2011, Benson Schliesser wrote:

> My opinion is that if we say that a CGN "SHOULD" do bulk port 
> allocation, then we should also say that it "MAY" do per-connection port 
> allocation (based on the rationale I just described).  Thoughts on this?

It's my opinion that it SHOULD support both, and that this SHOULD be user 
configurable.

---

From: ssenthil <[email-masked]>
Date: Mon, 31 Oct 2011 15:17:58 -0400

On 10/29/11 1:20 AM, "Cameron Byrne" <[email-masked]> wrote:

>> I tend to agree with your conclusion.  However, if we do per-connection
>> allocation of ports, then there might be benefits to the CGN operator and
>> users.  For instance, there might be improved security and more efficient
>> utilization of CGN port resources.  Thus, an operator that doesn't care about
>> logging might not want to use bulk port allocation.
>> 
>> My opinion is that if we say that a CGN "SHOULD" do bulk port allocation,
>> then we should also say that it "MAY" do per-connection port allocation
>> (based on the rationale I just described).  Thoughts on this?
>> 
> 

I agree that the recommendation should not be towards one mechanism over the
other. I have customers who use per-connection logging  who never
complained. It should be upto the network operator to choose what is best
for their deployment.

Senthil

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 31 Oct 2011 22:32:52 -0700

I agree. What about "SHOULD" support per-connection if logging is not
needed. "SHOULD" support bulk port allocation if Logging is needed.

Cheers,
Olivier

On 10/28/11 8:21 PM, "Benson Schliesser" <[email-masked]> wrote:

>utilization of CGN port resources.  Thus, an operator that doesn't care
>about logging might not want to use bulk port allocation.
>