Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

From: Tina TSOU <[email-masked]>
Date: Sat, 28 Aug 2010 17:18:54 +0800

Hi Behaver,
Here is an updated version, thanks to the wonderful review from Med.
http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-01

It is a short, straight forward I-D. I would like to hear your opinion and more comments. What's the next step for it?

B. R.
Tina
http://tinatsou.weebly.com/index.html

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Aug 2010 21:30:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Saturday, August 28, 2010 2:19 AM
> To: [email-masked]
> Subject: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs
> 
> Hi Behaver,
> It is a short, straight forward I-D. I would like to hear your opinion
> and more comments. What's the next step for it?

Should the block-allocated source ports be re-used?  If so, can text
be added to describe advantages / disadvantages of such re-use?

Can a NAT operator determine when a server operator is logging the
source port?

What is the impact if a server is not logging the source port?  For
example, what happens if a subscriber made a post to a web
server and law enforcement asked the ISP for the identity of the
subscriber, but the server didn't log the source port?  This seems
to place the ISP in a difficult situation, requiring the ISP to
reveal the identity of all subscribers that were using that IP
address at that time.

In an appendix it would be useful to provide configuration examples 
for popular server software to log the source port (e.g., Apache, 
IIS, Postfix, Sendmail, sshd, Cyrus IMAP, UW IMAP).  For example, I 
believe it was in Apache version 2.1 that added the ability to log 
the source port using "%{remote}p" described at 
http://httpd.apache.org/docs/2.1/mod/mod_log_config.html.  
And be sure to mention that, for all log file modifications, the 
source port needs to be added to the log in a way that will work 
with the server's log analysis scripts.

-d

---

From: Tina TSOU <[email-masked]>
Date: Tue, 31 Aug 2010 17:25:27 +0800

B. R.
Tina
----- Original Message ----- 
From: "Dan Wing" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; <[email-masked]>
Sent: Monday, August 30, 2010 12:30 PM
Subject: Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

> be added to describe advantages / disadvantages of such re-use?
[Tina] Thanks for your thorough review. OK, will add a section to describe 
the advantages/disadvantages

Source port blocks could be reused. When a port block is not used by a user 
for a while, the NAT device could allocate this port block to another user.

If a port block is not reusable, there could be two scenarios:

1. Statically configure the same number of ports for each user, e.g. each 
can have 2000 ports in this case, there may be a waste of source port 
resource, because maybe not all the users would need so many ports; 
meanwhile some users may need more ports

DS-Lite draft has some discussion about port allocation, 
http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06#section-8.4

2. Initially, give a user a port block, e.g. a block of 300 ports; when the 
user need more port, give the user another port block, e.g. a block of 100 
ports, and so on

In this case, a user may need a lot of ports for a while, but later this 
user does not need so many ports, one or more port blocks could be released.

Compared to the above two cases, if a port block is reusable, I can increase 
the usage of port resource.

However, if the block is not reusable, the implementation could be a bit 
simpler, e.g. timeout for a port block would not be necessary.

> Can a NAT operator determine when a server operator is logging the
[Tina] No, a NAT operator can not determine that.

> reveal the identity of all subscribers that were using that IP
[Tina] The impact is that it may not be possible to trace back to a single 
if a server is not logging the source port.

A NAT device can log the destination IP address of each session, though that 
would not resolve all the problems.

Now a CGN (Carrier Grade NAT) may need to support 10000+ users, it is quite 
possible that some users behind a same NAT would visit a same famous web 
server, like YouTube, at the same time. In such a case, if the server does 
not log the source port and the NAT log the destination IP address, I can 
not trace back to a single user, even if "the ISP to reveal the identity of 
all subscribers that were using that IP address at that time".

Since it is required by regulations (rather than by ISP), the server should 
be liable to log the source port.

This is discussed in draft-ietf-intarea-shared-addressing-issues-01

http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01#section-11

> with the server's log analysis scripts.
[Tina] To be honest, I do not know much about all kinds of the server 
software, I only do network devices. However I will try to find out 
whether/how they could log source port, and if possible I will add an 
appendix. I need help from the list for this point.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Aug 2010 08:46:55 -0700

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2010 2:25 AM
> To: [email-masked]; Dan Wing

It is useful to point that out in the I-D.

> if a server is not logging the source port.

Agreed.  It is useful to point that out in the I-D.

> A NAT device can log the destination IP address of each session, though
> that would not resolve all the problems.
> 

Agreed.  It is useful to point that out in the I-D.  

So, the scenarios are:

 1. IF server logs source port of incoming connections,
      THEN the NAT does not need to log destination.  The
      server's logs and the NAT's source port logs will be
      sufficient to identify the subscriber.

 2. IF server does not log source port of incoming connections,
      AND the NAT does not log destination
      THEN the ISP cannot identify which subscriber made the
           connection to the server.  This might mean the
           ISP has to disclose the identity of all the 
           subscribers that were sharing that IP address.

  3. If server does not log source port of incoming connections,
       AND the NAT does log destination
       THEN the ISP can identify the subset of users that 
            were accessing that server at that time, but
            the ISP cannot identify the specific user in
            that subset.

(And, as we agreed above, it is impossible for the NAT to 
determine if the server is logging the source port, so the
NAT cannot distinguish between 1 and 2 or between 1 and 3).

> Since it is required by regulations (rather than by ISP), the server
> should be liable to log the source port.

What is "it"?  I guess you are referring to regulatory requirements that
servers log ports?  I am aware of some activity with some regulatory 
agencies to include source port in their recommended/required logging, 
but I also know that those changes are not yet final.

> appendix. I need help from the list for this point.

The I-D is explaining the drawbacks of logging destination port and 
the I-D is encouraging server operators to log the source port.  It seems
useful to point out how easily the server operators can add source port
logging.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 31 Aug 2010 11:49:20 -0400

Hello Tina,

We have experience with this method and would like to suggest the following
be explained in the draft.

1 - What is a user? A private source IP address?

2 - Sessions that use the ports within a block will end at different times.
Do you return the ports to the main port pool?

2.1  - If you return the ports individually to the pool you will not have
contiguous ports after some time (even if you want to). If you do not not,
your basically statically carving out resources and making poor use of the
port space.

3 - If you log the deallocation for every port how much are you actually
saving? If you wait for all ports to be freed to send a single log, it might
take a long time and you are back to statically carving out resources.

4 - If the port are not contiguous you save the source IP and Dest IP but
still need to list every port. The main effect of not having contiguous port
is that the allocation of ports takes much longer whenever a 'user' is seen.

4.1 - When will you 'forget' about a user? If you forget about it when all
his/her sessions are are gone, you will be trying to allocate blocks of
ports often.

Thanks,

Reinaldo

On 8/28/10 2:18 AM, "Tina TSOU" <[email-masked]> wrote:

> It is a short, straight forward I-D. I would like to hear your opinion and
> more comments. What's the next step for it?
> 
> 
> B. R.
> Tina

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Aug 2010 12:08:02 -0400

I may be missing something, but given the variations, it seems a heck of 
a lot more reliable, and more compliant with rules, for operator NATs to 
log what information they can, and for server logging to be a separate 
matter.
The quesiton of how the NAT writes its logs, and what it writes, depends 
upon the style of NAT and other implementation details.
(For full cone NAT, it seems that logs which show source port 
allocation, with timestamps, are sufficient to meet most regulatory 
regimes.)

Yours,
Joel

---

From: Tina TSOU <[email-masked]>
Date: Wed, 01 Sep 2010 12:00:01 +0800

B. R.
Tina

----- Original Message ----- 
From: "Dan Wing" <[email-masked]>
To: "'Tina TSOU'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 31, 2010 11:46 PM
Subject: RE: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

> It is useful to point that out in the I-D.
[Tina] OK, will add it in -02 version.
> Agreed.  It is useful to point that out in the I-D.
[Tina] OK, will add it in -02 version.
> NAT cannot distinguish between 1 and 2 or between 1 and 3).
[Tina] OK, will add it in -02 version.
> but I also know that those changes are not yet final.
[Tina] Yes, you are right.
> useful to point out how easily the server operators can add source port
[Tina] will try to add it in -02 version.