Re: [BEHAVE] predictable translations

Chris Donley <C.Donley@cablelabs.com> Mon, 26 September 2011 18:43 UTC

Return-Path: <C.Donley@cablelabs.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8A21F8E17 for <behave@ietfa.amsl.com>; Mon, 26 Sep 2011 11:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.078
X-Spam-Level:
X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bkz3qIv+f3X for <behave@ietfa.amsl.com>; Mon, 26 Sep 2011 11:43:18 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2C21F8E16 for <behave@ietf.org>; Mon, 26 Sep 2011 11:43:18 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p8QIjOGY021759; Mon, 26 Sep 2011 12:45:24 -0600
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Sep 2011 12:45:24 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Sep 2011 12:45:25 -0600
From: Chris Donley <C.Donley@cablelabs.com>
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "'behave@ietf.org'" <behave@ietf.org>
Date: Mon, 26 Sep 2011 12:45:20 -0600
Thread-Topic: [BEHAVE] predictable translations
Thread-Index: Acx8fHNnFxGJWsgAT0O7RKMBA3Y2kg==
Message-ID: <CAA623B0.245A2%c.donley@cablelabs.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A88D48E3@szxeml526-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CAA623B0245A2cdonleycablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [BEHAVE] predictable translations
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2011 18:43:25 -0000

Tina,

Yes, this draft makes use of bulk port assignments once a user exceeds the deterministic port range. We view your draft as a component of a deterministic NAT.

Chris

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com<mailto:Tina.Tsou.Zouting@huawei.com>>
Date: Mon, 26 Sep 2011 12:00:41 -0600
To: Chris Donley <c.donley@cablelabs.com<mailto:c.donley@cablelabs.com>>, "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com<mailto:kristian.poscic@alcatel-lucent.com>>, "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>, "'behave@ietf.org<mailto:'behave@ietf.org>'" <behave@ietf.org<mailto:behave@ietf.org>>
Subject: RE: [BEHAVE] predictable translations

Chris,
Does this draft work with
http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-02
?

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

From: behave-bounces@ietf.org<mailto:behave-bounces@ietf.org> [mailto:behave-bounces@ietf.org] On Behalf Of Chris Donley
Sent: Monday, September 26, 2011 10:56 AM
To: Poscic, Kristian (Kristian); mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; 'behave@ietf.org<mailto:'behave@ietf.org>'
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)" <kristian.poscic@alcatel-lucent.com<mailto:kristian.poscic@alcatel-lucent.com>>
Date: Fri, 23 Sep 2011 10:21:13 -0600
To: "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>, "'behave@ietf.org<mailto:'behave@ietf.org>'" <behave@ietf.org<mailto:behave@ietf.org>>
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:mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, September 22, 2011 11:00 PM
To: Poscic, Kristian (Kristian); 'behave@ietf.org<mailto:'behave@ietf.org>'
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 :behave-bounces@ietf.org<mailto:behave-bounces@ietf.org> [mailto:behave-bounces@ietf.org] De la part de Poscic, Kristian (Kristian)
Envoyé : vendredi 23 septembre 2011 01:28
À : 'behave@ietf.org<mailto:'behave@ietf.org>'
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: behave@ietf.org<mailto:behave@ietf.org>
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