Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt

[Dan Wing <[e-mail]>]

On Apr 3, 2013, at 7:39 PM, kaname nishizuka <[e-mail]> wrote:

> Thank you for your comments,
> 
>> [Senthil] Most of the NATs use the entire port space from 1024-65536, did you find differently?
>> 
>> If you had used the entire port space, you would only require 1526 addresses instead of 3051.
>> 
>> I think not using the 1024-32768 is not practical and inefficient.
> What you pointed out is reasonable enough, but our concern is that there are de-facto well-known port in 1024-32768 like 1433/tcp.
> Especially in the static assignment, the subscriber who has a "dirty" range would be attacked more frequently than others.

No more so than every subscriber is being attacked on those ports today, when subscribers are getting the entire port range.

-d

> We know that most of the NATs use the  entire port space from 1024-65536, but we described it in the most safe side.
> As you mentioned, the ratio of dynamic:static is the same.
> 
> 
>> [Senthil] I think it should be mentioned that with binary format for the above logging information, you need 26 bytes.
>> 
>> Transport Protocol -  1 byte
>> 
>> Source IP address:port – 6 bytes
>> Source IP address:port after translation – 6 bytes
>> Timestamp – 8 bytes
>> 
>> Add/Delete – 1 byte
>> 
>> Subscriber ID/VRF ID – 4 bytes
>> 
> I agree with that. It's useful and it supports the logic.
> 
> Thanks,
> kaname
> 
> (2013/04/03 7:03), Senthil Sivakumar (ssenthil) wrote:
>> Hi Kaname,
>> It is a pretty interesting study. I have a few comments on the sections on your IP address requirements calculations.In the dynamic assignment, the ports of pool address are allocated
>> 
>> 
>> 
>> 
>> 
>> "   # of pool address (P) = # of Subscriber (S) * a * N / (65536 - R)
>> 
>>   Here, (R) is reserved TCP/UDP port list referred in
>>   [I-D.donley-behave-deterministic-cgn<http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#ref-I-D.donley-behave-deterministic-cgn>].  CGN should eliminate the
>>   wellknown ports (0-1023 for TCP and UDP) to avoid the bad
>>   interpretation from destination servers.  It is natural to translate
>>   source port of outgoing packet to ephemeral ports.  The ports after
>>   32768 is considered to be used without any problems because ephemeral
>>   ports are 32768-61000 for Linux and 49152-65535 in the IANA
>>   recommendations.  As the result, 3,051 pool addresses are sufficient
>>   for 1,000,000 subscribers.  The feasibility of configuration was
>>   confirmed in the verification."
>> 
>> [Senthil] Most of the NATs use the entire port space from 1024-65536, did you find differently?
>> 
>> If you had used the entire port space, you would only require 1526 addresses instead of 3051.
>> 
>> I think not using the 1024-32768 is not practical and inefficient.
>> 
>> 
>> 
>>   On the other hand, in static assignment, the ports are allocated a
>>   priori for every users.  The pool addresses and ports are reserved to
>>   every users, so most of them could be a dead stock because there are
>>   light users and heavy users in aspect of port consumption.  The max
>>   number of port consumption in all subscribers is the key value for
>>   static assignment.  The true peak number of the session by a heavy
>>   user could be over 10,000 sessions.  However it is assumed that such
>>   a severe consumption of ports to be an abuse, so the number of
>>   statically assigned port (M) is controllable parameter by each
>>   providers.  In the static assignment, the required number of the pool
>>   address is as follows:
>> 
>>   # of pool address (P) = # of Subscriber (S) * M / (65536 - R)
>> 
>>   Taking account into the investigation of number of sessions of
>>   applications, the desirable value of (M) is over 1,000.  As the
>>   result, no less than 30,517 pool addresses are needed for 1,000,000
>>   subscribers.  The compression ratio is one tenth of the case of
>>   dynamic assignment."
>> 
>> 
>> [Senthil] Going by the same standards of using the entire available port range, you should require 15259 addresses.
>> But the point is the cost of static allocation to dynamic allocation is 10:1, which is huge and given the fact there is only so little
>> address space that is available, it should be used efficiently. Just by looking at that calculation, it seems amply clear that dynamic is preferred over static,
>> as you have noted.
>> That leads us to the next topic on logging.
>> 
>> 
>> 
>>  " In addition, the indicator of the allocation and deallocation are
>>   needed because it assures that the identified subscriber certainly
>>   had been using the translated IP address and port.  Plus, including
>>   the index of the CGN host, the average size of NAT log is about 120
>>   byte in ASCII format.  Every active subscriber generate 400 sessions
>>   in average for a certain amount of time.  It is assumed that the
>>   event happens every 5 minute in the most severe condition.  The size
>>   of the log (L) for time frame (T) can be estimated as follows:
>> 
>>   The size of log (L) = # of Subscriber (S) * a * N * 120byte * 2 * (
>>   Time frame(T) / 5 min. )
>> 
>> 
>> 
>>   It should be noted that the log is generated at the timing of NAT
>>   table creation and freeing.  As the result, for 1,000,000 users, the
>>   size of log is piled up to 6.4 terabytes per day.  The verification
>>   result confirm the existing estimation referred in
>>   [I-D.donley-behave-deterministic-cgn<http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#ref-I-D.donley-behave-deterministic-cgn>]."
>> 
>> [Senthil] I think it should be mentioned that with binary format for the above logging information, you need 26 bytes.
>> 
>> Transport Protocol -  1 byte
>> 
>> Source IP address:port – 6 bytes
>> Source IP address:port after translation – 6 bytes
>> Timestamp – 8 bytes
>> 
>> Add/Delete – 1 byte
>> 
>> Subscriber ID/VRF ID – 4 bytes
>> 
>> 
>> I would help a lot to add the binary logging calculation in addition to the ascii format to help people choose the right method for them.
>> 
>> Going by the same formula you need 1.36 TB/day with binary logging. Assuming that the compression ratio is the same
>> 
>> For both ascii and binary data, you have 1/4-1/5th of advantage with binary logging.
>> 
>> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming cost of 1TB is US$80,
>> 
>> we come to 0.00008 cents/subscriber/day or 0.024 cents/subscriber/month. Even with ASCII logging requirements this doesn’t sound like a mammoth cost.
>> 
>> Sure, there are other operating expenses involved but comparing that with the efficiency of a dynamic port allocation mechanism and requiring 10 times less
>> 
>> public addresses seems to be a compelling winning argument than changing every CGN implementation to save for logging costs.
>> 
>> 
>> Thanks
>> 
>> Senthil
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: kaname nishizuka <[e-mail]<mailto:[e-mail]>>
>> Date: Tuesday, April 2, 2013 4:37 AM
>> To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>> Cc: Shin Miyakawa <[e-mail]<mailto:[e-mail]>>
>> Subject: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
>> 
>> 
>> Dear all,
>> 
>> I'm kaname from NTT communications in Japan.
>> We are testing CGN under the support of Japanese Government.
>> Now, we've uploaded a new draft based on the result of our verification.
>> The useful information about the average consumption of the ports are available on the document.
>> Please look through it, and all kind of feedback are welcome.
>> 
>> By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon.
>> 
>> The document is *NOT* intended to be Standards Track. It's for Informational.
>> The wrong description is just mere mistake, so we'll soon correct it in the next revision.
>> 
>> The full report of our work will be available soon on the Web in English.
>> I'll also announce it when it's available to this mailing-list.
>> 
>> Best regards,
>> 
>> kaname
>> 
>> 
>> 
>> 
>> 
>> -------- Original Message --------
>> Subject:        New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
>> Date:   Thu, 28 Mar 2013 07:12:25 -0700
>> From:   [e-mail]<mailto:[e-mail]>
>> To:     [e-mail]<mailto:[e-mail]>
>> 
>> 
>> 
>> A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt
>> has been successfully submitted by Kaname Nishizuka and posted to the
>> IETF repository.
>> 
>> Filename:        draft-nishizuka-cgn-deployment-considerations
>> Revision:        00
>> Title:           Carrier-Grade-NAT (CGN) Deployment Considerations.
>> Creation date:   2013-03-29
>> Group:           Individual Submission
>> Number of pages: 16
>> URL:             http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations
>> Htmlized:        http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00
>> 
>> 
>> Abstract:
>>   This document provides deployment considerations for Carrier-Grade-
>>   NAT (CGN) based on the verification result include the investigation
>>   of the number of sessions of applications.  The verification was
>>   conducted in StarBED which is one of the largest scale network
>>   experiment environment in Japan.  A million of subscribers was
>>   emulated and it revealed the realistic behavior of CGN.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> ----
>> Kaname Nishizuka
>> Innovative Architecture Center
>> NTT Communications Corporation
>> [phone]
>> 
> 
> 
> -- 
> ----
> Kaname Nishizuka
> Innovative Architecture Center
> NTT Communications Corporation
> [phone]
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave