Hi Peter,
There are serious security issues with the idea of having a host on
the receiving end "automatically undo" something that will give the
impression that a packet was actually received from a different
address. For example, an external source address could be used to
pass ingress filtering rules at a border router, and then the address
could be switched "back" to an address that appears to have originated
locally. This could be used as the basis for an attack. The "TRIP"
proposal I circulated had the same problem... There are potential
solutions to this problem, such as having the addresses
cryptographically generated, but they would have to be spelled out in
detail for any proposal along these lines to be secure.
Also, how is the receiving host supposed to send traffic back to the
source? Which address would it use?
I don't think I understand how your proposal would work, unless both
the internal and external addresses are globally routed addresses. If
that is the case, what benefit is gained from having two sets of
addresses? Even if you did globally route both sets of addresses, I
am still having some conclusion about what addresses will be seen by
the transport layer (and apps) on both ends.
Could you perhaps write an Internet-Draft describing your proposal, so
that we can discuss it in detail? It should include an explanation of
how a client gets the IP address(es) for a remote host, how it
initiates a connection, how the remote host responds, what addresses
the transport layers will see on both ends, how the local host's
transport layer associates the response with the connection it
initiated, etc.
Also, could you explain which of the benefits of IPv4 NAT are
preserved in your solution?
Thanks,
Margaret
On Dec 5, 2008, at 8:42 PM, Peter Dambier wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Keith,
the NAT66 I might get from my ISP is almost native IPv6.
The tunnel I might get from a tunnel broker means a loss
of speed and yet another dependence on somebody else.
Of course an IPv6 port of TOR would be a good idea.
Maybe I should talk to the TOR people.
But I am afraid that is not the tunnel you meant.
Connecting customers via aDSL and PPPoE my ISP does already
put me through a tunnel and he does already take some bytes
away.
I dont want a NAT in the first place but I prefer a NAT66
that can be undone by a symmetric NAT66 to an opaque one.
Kind regards
Peter
Keith Moore wrote:
Peter Dambier wrote:
I would very much like to have an extension header for NAT66.
That would allow symmetric NAT66 to automatically undo what
a NAT66 has done.
If you're going to incur per-packet overhead for the sake of
reversing
the address translation, why not just tunnel?
Keith
_______________________________________________
Behave mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/behave
- --
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJOdh+oQA0qetcyygRAuqwAJ4jh5HvZSckODCPyitXF7Qpfg9pcgCfZAep
frNw0I4d0ZVzvL1gJh6sIrw=
=hW7V
-----END PGP SIGNATURE-----
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
