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

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?

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.

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.

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.

Thanks,

Wes George

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Fred Baker
> Sent: Tuesday, October 11, 2011 9:52 AM
> To: v6ops v6ops WG
> Cc: Behave Chairs; draft-donley-behave-deterministic-cgn@tools.ietf.org
> 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
> v6ops@ietf.org
> 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.