Re: [BEHAVE] predictable translations

[Chris Donley <[e-mail]>]

Kris,

Please see in-line.

Chris

From: "Poscic, Kristian (Kristian)" <[e-mail]<mailto:[e-mail]>>
Date: Mon, 26 Sep 2011 13:18:54 -0600
To: Chris Donley <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'[e-mail]<mailto:'[e-mail]>'" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [BEHAVE] predictable translations

Thanks Chris!
I was wondering how would one extend the port-block in deterministic-CGN for an inside IP address if all the ports in the originally assigned port-block are exhausted.
It looks like that you combined deterministic NAT with the dynamic port assignment through the D variable, which I think is a good compromise.

As I understand In you example, you eliminated inside addresses 192.168.0.0 and 192.168.0.15 from the range 192.168.0.0/28, and in essence allocated their share of outside ports via the D factor to the dynamic allocation. Nice.

A few questions:

-          Do you always assume that the 0 and bcast host part of the inside IP address range is automatically excluded from ‘I’?

I suppose that it could go either way, but in our analysis, we think ISPs will deploy CGNs in such a way as to not allocate the network/bcast addresses to subscribers. YMMV, and it would be up to CGN vendors and ISPs to decide whether to include them, or whether there were additional addresses to exclude.

-          You mentioned on page 4, point 2 in the last sentence: “ Subscribers could be restricted to ports from a single IPv4 address, or could be allocated ports across all addresses in a pool, for example”. Do you mean that this can be done in  a deterministic fashion? In other words, can an inside IP address spawn more outside IP addresses in a deterministic fashion (along with outside port ranges)?

Sure.  Simplistic example – 4 subs/2 outside addresses.  You could chop up each of the outside addresses in 4 blocks: 0-16K, 16-32K, 32-48K, 48-64K. Sub 1 gets the low address range on both outside addresses, sub 2 gets the next highest range, etc.

-          It is up to the vendor to figure out how will ports be assigned (in block, staggered fashion, etc). There are requirements out there that the ISPs run the algorithm on external nodes to do to reverse conversions. So this inconsistency will make life for ISP little bit more difficult, but I guess as people mentioned here, we can’t mandate the details of the algorithm to the vendors.

Perhaps vendors could include their algorithm in the daily log message, document it somewhere so that the ISPs could script the reverse mapping, or supply a tool.  ISPs will be able to determine what CGN is hosting which address and run the appropriate tool, if necessary.

-          I know that this is the first version of the draft, but in the future maybe you can mention load balancing across the modules performing the NAT function in the system and if there is anything in particular that you had in mind about this…

Sure. We'll definitely consider it for a future update.

Thanks,
Kris




From: Chris Donley [mailto:[e-mail]]
Sent: Monday, September 26, 2011 10:56 AM
To: Poscic, Kristian (Kristian); [e-mail]<mailto:[e-mail]>; '[e-mail]<mailto:'[e-mail]>'
Subject: Re: [BEHAVE] predictable translations

Kris,
We've been working on such an idea at CableLabs. I've been a little slow to post.

We're definitely interested in your feedback on our proposal.

Chris

A new version of I-D, draft-donley-behave-deterministic-cgn-00.txt has been successfully submitted by Chris Donley and posted to the IETF repository.

Filename:  draft-donley-behave-deterministic-cgn
Revision:  00
Title:         Deterministic Address Mapping to Reduce Logging in Carrier Grade NATs
Creation date:  2011-09-26
WG ID:         Individual Submission
Number of pages: 9

Abstract:
   Many Carrier Grade NAT solutions require per-connection logging.
   Unfortunately, such logging is not scalable to many residential
   broadband services.  This document suggests a way to manage Carrier
   Grade NAT translations in such a way as to significantly reduce the
   amount of logging required while providing traceability for abuse
   response.  This method also provides a way of including geo-location
   significance in such assignments.





The IETF Secretariat

From: "Poscic, Kristian (Kristian)" <[e-mail]<mailto:[e-mail]>>
Date: Fri, 23 Sep 2011 10:21:13 -0600
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'[e-mail]<mailto:'[e-mail]>'" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [BEHAVE] predictable translations

Hi Med,
By predictable translation I mean deterministic NAT.

For now, I’m just trying to evaluate (for my own sake) if this deterministic NAT makes any sense since 1) would take care of the concerns that I have. If deterministic NAT makes deployable sense [for a reason that I yet need to find, since 1) already takes care of my concerns], then I’m trying to evaluate surrounding issues related to ease of integration into existing OS  (which it looks like does not come into play) and any other legal issues related to use of already possibly patented algorithms.

Thanks,
Kris

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, September 22, 2011 11:00 PM
To: Poscic, Kristian (Kristian); '[e-mail]<mailto:'[e-mail]>'
Subject: RE: predictable translations

Dear Kris,

Could please precise more what you mean by "predictable translation"?

(1) Do you want to eliminate the volume of CGN logs (e.g, few entries per customer) or (2) you want to eliminate the CGN logging (e.g., rely on DHCP records)?

(1) can be done in the CGN itself by design or configuration of the CGN to use port ranges. This is already supported by CGN implementation including A(..)U ;-)

(2) can be supported only if you eliminate the NAT function in the CGN which should be a PRR (Port Range Router; http://tools.ietf.org/html/draft-boucadair-port-range-02#section-6) instead.


Cheers,
Med

________________________________
De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] De la part de Poscic, Kristian (Kristian)
Envoyé : vendredi 23 septembre 2011 01:28
À : '[e-mail]<mailto:'[e-mail]>'
Objet : Re: [BEHAVE] predictable translations
I looked at this draft draft-bsd-softwire-stateless-port-index-analysis-00<http://datatracker.ietf.org/doc/draft-bsd-softwire-stateless-port-index-analysis/> which examines 6 different algorithms for predictable translation applicable to v4/v6 translation but I guess it can be potentially adopted for v4 to v4 conversions as well.

As my coworker (who is probably on this list) says “too many deterministic nat drafts make for non-deterministic behaviours”.
Is there any plan to adopt one as a standard?
Thanks,
Kris

From: Poscic, Kristian (Kristian)
Sent: Thursday, September 22, 2011 11:57 AM
To: [e-mail]<mailto:[e-mail]>
Subject: predictable translations

Hi there –
Does anyone knows of any draft that is addressing a more predictable translations between the inside IP and outside IP + port range when it comes to NAT44.
For example in order to avoid logging, IPv4 inside address would be automatically (via an algorithm) be converted to an outside IPv4 address  + a port range. This mapping would be unique so that no logging is required. The revertive algo would be able to convert the outside IP + port back  to the inside IP.

I’ve seen some drafts addressing something similar in the softwire WG but they all deal with IPv4/IPv6 translations.
Thanks,
Kris