Re: [v6ops] Please review draft-donley-behave-deterministic-cgn

[Chris Grundemann <[e-mail]>]

Thanks for the feedback Wes,

I'm digging in to prepare a -01 so am reviewing all the comments to dateŠ
Comments inline below.

Cheers,
~Chris


On 10/11/11 2:43 PM, "George, Wes" <[e-mail]> wrote:

>I'm not sure why this draft is classified as experimental and not
>informational or even standards track formally updating RFC6264 and/or
>shirasaki-nat444.
>
>After reading this:
>http://www.ietf.org/old/2009/u/ietfchair/info-exp.html I'm still not sure
>why. Can someone involved in the discussion apply the clue brick?

I'll allow those more versed in the intricacies of IETF doc types step in
here as to the preferred classification - I do not believe that we are
married to experimental if another class is deemed more appropriate.

>In terms of the meat of the document, I think that the document needs to
>cover the case where ports are not allocated sequentially (such as in
>order to reduce the determinisim and make it harder for a rogue entity to
>guess the next port, or for privacy reasons). It may work basically the
>same way as when a subscriber exceeds their pre-allocated ports, but the
>draft should explicitly cover this.

I may be misunderstanding but I believe this is covered in Section 2, Step
2, which reads in part:

"Port allocation could be made sequentially (e.g. the first block goes to
address 1, the second block to address 2, etc.), staggered (e.g. address 1
receives ports n*(C+D), address 2 receives ports 1+n*(C+D), etc.), or
through some other deterministic algorithm left to CGN implementation.
Subscribers could be restricted to ports from a single IPv4 address, or
could be allocated ports across all addresses in a pool, for example."

>Also, it would be good to discuss failover cases - how much (if any)
>state has to be maintained between CGNs in order to ensure adequate
>logging information is available during common failover cases (failure
>within the CGN instance, failure between two standalone CGN instances,
>etc). I'm not suggesting discussion of how to make a CGN fail over, I'm
>only talking about the considerations unique to this implementation.

I'm not opposed to adding a section covering failover but I believe that
it would be fairly simple.

Since the reservations are deterministic, knowing the outside IP should
lead you to the proper CGN instance (whether in failure mode or not) and
having the IP and port will allow the reverse mapping on that instance
(again, does not matter if the instance is the primary or secondary).

This holds true if the instances are active/passive and a primary failure
causes sessions to break and re-connect over the secondary, or in an
active/active cluster arrangement where the outside IP pool is shared
between multiple active CGN instances.

Perhaps I'm missing something though, and this is more complicated than I
propose.

>Lastly - the draft should recommend (possibly even a MUST) that
>implementers should provide a means to reverse the mapping algorithm. One
>of the challenges for any mapping algorithm is that one must understand
>it well enough to reverse it, and either do manual calculations to
>determine the mapping, or write a tool to do it. The path chosen largely
>depends on the frequency of the requests for that type of information. It
>makes far more sense for the implementer to make their mapping available
>in both directions so that there is no guesswork on the part of the
>operator as to whether they are reverse-engineering the mapping properly
>to arrive at the correct result.

I will talk about this with the other authors, however, I tend to agree
that this should at least be suggested, if not required.

>Thanks,

Thank you!

>Wes George
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Fred Baker
>> Sent: Tuesday, October 11, 2011 9:52 AM
>> To: v6ops v6ops WG
>> Cc: Behave Chairs; [e-mail]
>> Subject: [v6ops] Please review draft-donley-behave-deterministic-cgn
>>
>> Operators subject to law enforcement subpoenas and using Carrier Grade
>> NAT are having difficulties with the syslog rate for per-connection
>> logging. Chris Donley has proposed a simplification; the provider
>> allocates a deterministic set of source ports to his subscribers, and
>> only needs to log exceptions. Research in the area suggests that usage
>> of source ports is pareto distributed; a typical user has a requirement
>> on the order of 4 port numbers in simultaneous use (median), but port
>> scans and other large volume uses drive the average quite a bit higher.
>>
>> They haven't asked for it, but I suspect the behave chairs would
>> appreciate operational commentary on the draft.
>>
>> http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn
>>   "Deterministic Address Mapping to Reduce Logging in Carrier Grade
>> NATs",
>>   Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan,
>>   26-Sep-11
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.