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

[<[e-mail]>]

Dear Lars, all,

The use of port ranges instead of assigning individual port in CGNs has several effects, not only optimising the logs:

(1) The performance of the device are not impacted due to the writing operation (of each individual binding). For some implementations, we have seen a severe degradation when the device (in our case, it is a CGN DS-Lite) must log each individual entry. Note that, we have seen some implementations which loss packets when the port range bindings are not yet in place. But, I guess this is implementation-specific. 

(2) The amount of new sessions to be handled per second are drastically enhanced when a port range scheme is used instead of individual port assignment.
 
(3) As an aside effect, when port ranges are used the size of the log file is optimised (FWIW, see http://tools.ietf.org/html/draft-boucadair-port-range-02#section-15.2 for a simplified exercise). Of course this optimisation depends on length of the port range.

(4) The drawback of assigning port ranges in the CGN is that the destination address is not kept by the device. This may not be convenient in early stages of deployment of shared IP mechanisms in SPs domains. Indeed: 

(a) If a high address sharing ratio (e.g., 1:1000) is used, to avoid revealing the identity of all subscribers sharing the same address to answer to an abuse complaint by the authorities, we may rely on the destination address as an indicator to identify a/the concerned customer. In the meantime, we need to encourage servers to log the source port number in addition to the destination IP address. 
(b) If a small address sharing ratio (e.g., 1:5) is used, storing the destination address in the CGN may not be useful. 


Cheers,
Med 

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Lars Eggert
Envoyé : vendredi 3 septembre 2010 10:49
À : Tina TSOU
Cc : [e-mail]
Objet : Re: [BEHAVE] Port Management To Reduce Logging In Large-Scale NATs

Hi,

On 2010-8-28, at 12:18, Tina TSOU wrote:
> 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?

I'm struggling a bit to understand the motivation for this draft. In the introduction, it says:

>   Some high performance NAT devices may need to create a large amount
>   of new sessions per second.  If logs are generated for each mapping
>   entry, the log traffic could reach tens of megabytes per second or
>   more, which would be a problem for log generation, transmission and
>   storage.

Let's run some numbers. How large is a log entry? Let's assume two IPv4 addresses plus two ports numbers, which is 12 bytes, plus a timestamp, which is maybe 4 bytes, plus some random bytes of stuff. Say, in total 32 bytes.

At a rate of     1,000 bindings/sec, that causes  32 KB/sec of log traffic.
At a rate of    10,000 bindings/sec, that causes 320 KB/sec of log traffic.
At a rate of   100,000 bindings/sec, that causes   3 MB/sec of log traffic.
At a rate of 1,000,000 bindings/sec, that causes  32 MB/sec of log traffic.

So we're really only going to his the "tens of megabytes per second" range for CGNs that see a million bindings per second. You'd need an awfully big box to handle this, and a significant amount of IPv4 space to number it.

As for storage, with a million bindings per second and 32 MB/sec of log traffic, you need about 2GB/min, i.e., 2.7 TB/day. And this is without compression - these logs should be highly compressable.

All in all, I'm not fully convinced we have a problem here. Or maybe I'm missing something?

Lars
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************