Subject: [BEHAVE] Technical comment on draft-mrw-behave-nat66-00

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Nov 2008 11:24:30 -0700

Nice draft but few comments and questions.

I imagine this is a stupid question and I have not had enough coffee  
or something but, I don't understand both the Topology Hiding mapping  
works. Ignore all the checksum stuff for a second. Assume we have two  
internal hosts A and B that both happen to have same checksum for  
their internal IPs. They both send a packet to the same external host.  
It seems like they both get mapped to the same external address on the  
outside of the NAT. Later when the NAT receives a packet on that  
external address, how does it know to send it to A or B. What state  
would it store that allowed recover of if the packet went to A or B?

I've heard a few requirements around NATs for topology hiding. I'm not  
arguing any of these are valid or not, I'm just saying that some  
people believe they are and what we might do to meet them.

a) can change external numbering without renumbering inside - clearly  
your Two Way mapping solves this

b) hide internal IP from external observers - seems like the Topology  
Hiding mapping is supposed to solve this

c) hide from external viewers the fact that two different application  
sessions came from same internal host - I don't fully understand the  
Topology Hiding mapping but it seems like it would not do this.  
Perhaps you add a third type of mapping that did this. I can't really  
imagine how to do it without also looking at the internal source port  
and using that as part of seed to forming the external IP.

I might propose that you change the Topology Hiding mapping so that  
instead of setting the bits to zero, it sets them to a value formed by  
taking the internal IP and some secret, then applying a secure hash to  
get the bits for the external IP. The NAT would save in it's state  
table the mapping from the resulting external IP to the internal IP  
that generated it.

Similar a algorithm could be done for requirement c above that did  
roughly the above put also included the source port and protocol in  
the hash. A problem with such an algorithm is that applications where  
two session need to come from the same IP would not work. An example  
of this is using the fact [email-masked] authorized a POP session  
from a certain IP address means that that IP address is allowed to use  
SMTP to send email as fluffy. This would not work because the POP and  
SMTP session would appear to be from different external IP address.  
Unless of course the email client knew to use the same source port for  
both POP and SMTP. Although this approach has this limitation, it is  
probably better than the alternative approach would have the NAT end  
up doing port translations as well as address translations.

I get how you do the checksum neutral mapping adjustments. That is  
clever but I wonder if it is actually helps or if all the hardware we  
use trivial checks and compute checksums at line rate often in hardware.

Anyways, there is a few random thoughts - thanks for writing the draft,

Cullen

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Nov 2008 13:51:05 -0500

Hi Cullen,

On Nov 14, 2008, at 1:24 PM, Cullen Jennings wrote:
> or something but, I don't understand both the Topology Hiding  
> mapping works. Ignore all the checksum stuff for a second. Assume we  
> have two internal hosts A and B that both happen to have same  
> checksum for their internal IPs. They both send a packet to the same  
> external host. It seems like they both get mapped to the same  
> external address on the outside of the NAT. Later when the NAT  
> receives a packet on that external address, how does it know to send  
> it to A or B. What state would it store that allowed recover of if  
> the packet went to A or B?

As Tony Hain also pointed out in an earlier message, there does seem  
to be a bug in the Topology Hiding mapping that can result in multiple  
hosts using the same address.  Oops!  I have an idea about how to fix  
this (it's not that hard, since there is already state involved for  
the reverse mapping), and I'll try to formalize some examples for the  
behave meeting in MN (and for a new version of the draft after MN).
>
> I've heard a few requirements around NATs for topology hiding. I'm  
> not arguing any of these are valid or not, I'm just saying that some  
> a) can change external numbering without renumbering inside -  
> clearly your Two Way mapping solves this
>
> b) hide internal IP from external observers - seems like the  
> Topology Hiding mapping is supposed to solve this
>
> c) hide from external viewers the fact that two different  
> application sessions came from same internal host - I don't fully  
> understand the Topology Hiding mapping but it seems like it would  
> not do this. Perhaps you add a third type of mapping that did this.  
> I can't really imagine how to do it without also looking at the  
> internal source port and using that as part of seed to forming the  
> external IP.
>
> instead of setting the bits to zero, it sets them to a value formed  
> by taking the internal IP and some secret, then applying a secure  
> hash to get the bits for the external IP. The NAT would save in it's  
> state table the mapping from the resulting external IP to the  
> internal IP that generated it.

This is an interesting idea.

There are a number of things we could do in the topology hiding case,  
because we can reasonably expect to have at least 62 IID bits (not  
counting the two IID flags) to work with, perhaps in addition to some  
number of subnet bits (S).  In general, we can change any number of  
those 62+S bits, using whatever transformation we want, and then  
perform a checksum correction on any 16 of those bits to make sure the  
checksum matches the original checksum.  If our algorithm can result  
in more than one internal address getting the same external address,  
we can do something to resolve that (since we'll have state in the  
NAT66 device for reverse mapping and can detect the conflict).  Things  
we do to fix it could include:  incrementing, adding a randomly  
generated number, or running a randomizing algorithm again (if our  
initial algorithm included some randomization).  We coudl repeat the  
fix until we find an empty slot.

So, we have a lot of choices here, and I think we need to think about  
the best algorithm to use for a topology hiding transformation.  Your  
idea sounds much more promising than then one I have in the draft.

> the hash. A problem with such an algorithm is that applications  
> where two session need to come from the same IP would not work. An  
> example of this is using the fact [email-masked] authorized a POP  
> session from a certain IP address means that that IP address is  
> allowed to use SMTP to send email as fluffy. This would not work  
> because the POP and SMTP session would appear to be from different  
> external IP address. Unless of course the email client knew to use  
> the same source port for both POP and SMTP. Although this approach  
> has this limitation, it is probably better than the alternative  
> approach would have the NAT end up doing port translations as well  
> as address translations.

I think it might be better to use IPv6 privacy addresses for #3,  
because the local application would be better equipped to know whether  
it makes sense to obfuscate the IP addresses for a particular  
application (as opposed to doing a constant 1:1 mapping).
> clever but I wonder if it is actually helps or if all the hardware  
> we use trivial checks and compute checksums at line rate often in  
> hardware.

The purpose of the checksum neutral mapping is that it allows us to  
avoid changes to pseudo-header checksums in transport layer headers,  
which means that NAT66 boxes do not have to do any sort of deep packet  
inspection, know about all possible IPv6 extension headers, know about  
all possible transport layer headers, etc.

I don't think there is a lot of lower-end hardware out there today  
that already deals with transport layer pseudo-header checksum changes  
for IPv6, but I could be mistaken.  Also, there is a concern that  
requiring NAT66 devices to change the pseudo-header checksum in the  
transport layer will limit our ability to innovate at the transport  
layer.
> Anyways, there is a few random thoughts - thanks for writing the  

Thank you for the feedback.

Margaret