Subject: [BEHAVE] predictable translations

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Thu, 22 Sep 2011 13:56:44 -0500

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Sep 2011 22:24:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Poscic, Kristian (Kristian)
> Sent: Thursday, September 22, 2011 11:57 AM
> To: [email-masked]
> Subject: [BEHAVE] 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.

Sure, a NAT could be built that does exactly that.  Some vendors
have been doing exactly that, or something very similar.

How does the IETF fit into that, though?  That is, why is a standard
necessary?

-d

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

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Fri, 23 Sep 2011 00:37:09 -0500

In my opinion two points:
- if this is implemented to eliminate logging then there must be systems that do reverse conversion to find out who do original user was. It would make more sense that that systems doing the reverse conversion uses common (standardized) algorithm. Otherwise this solution will be very vendor specific and customers will be tied into vendor specific version of the algo.
- other potential issues are legal issues with patents, etc.
Kris 

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Thursday, September 22, 2011 10:25 PM
To: Poscic, Kristian (Kristian); [email-masked]
Subject: RE: [BEHAVE] predictable translations

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Sep 2011 22:47:24 -0700

> From: Poscic, Kristian (Kristian) [mailto:kristian.poscic@alcatel-
> lucent.com]
> Sent: Thursday, September 22, 2011 10:37 PM
> To: Dan Wing; [email-masked]
> - if this is implemented to eliminate logging then there must be
> systems that do reverse conversion to find out who do original user
> was. It would make more sense that that systems doing the reverse
> conversion uses common (standardized) algorithm. Otherwise this
> solution will be very vendor specific and customers will be tied into
> vendor specific version of the algo.

It's not possible to accomplish that, unless there is guarantee /
assurance that the subscriber's address (assigned to their CPE)
did not also change.  A+P/dIVI/4rd can't guarantee that.  Only
the ISP can do that with the combination of its knowledge of
what address it assigned to the CPE and how its address sharing
device was configured on that particular day.  Consider, for
example, a Tuesday night where users are changed from 300 ports
to 200 ports.  Only the ISP is aware of that change and when
that change occurred.  An entity on the Internet won't be 
aware.

I don't see how the requirement you're stating can be met.

-d

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Fri, 23 Sep 2011 11:11:06 -0500

Ok, so you're saying that the backward conversion must be limited to the NAT device itself. In other words one would via CLI 'show/display' commands on the NAT device enter the outside IP + port and the output would be the inside IP. Of course the NMS could also query the NAT device remotely. But there would be no external systems (back-end) that would be running the algorithm so do this conversion. Ok, makes sense.

Thanks,
Kris 

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Thursday, September 22, 2011 10:47 PM
To: Poscic, Kristian (Kristian); [email-masked]
Subject: RE: [BEHAVE] predictable translations

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Sep 2011 11:39:50 -0700

> Sent: Friday, September 23, 2011 9:11 AM
> Ok, so you're saying that the backward conversion must be limited to
> the NAT device itself. In other words one would via CLI 'show/display'
> commands on the NAT device enter the outside IP + port and the output
> would be the inside IP. Of course the NMS could also query the NAT
> device remotely. But there would be no external systems (back-end) that
> would be running the algorithm so do this conversion. Ok, makes sense.

Yes, I'm saying it's entirely the ISP's responsibility for how that
translation happens.

-d