[e2e] 100% NAT - a DoS proof internet

[Joe Touch]

Since that's basically what we already do in many apps, how would this help?

It's not enough to do that lookup in the endsystems, it has to happen
along the path, i.e., those IDs need to be in the packets. However, that
just invites NA(P)T designers to evolve to NAPNT (add name translation).

Yes, there are many ways to define away the problem:
	- NAT host to NAT host using a non-NAT host somewhere
		which won't exist if NATs are pervasive
	- NAT host to NAT host using a non-translated ID
		which means at least one of the hosts is not NAT'd
		(not 'translated ID') anymore

Joe


alok wrote:
> Hi,
> 
> Well, I meant something on the lines of modifying send() and recv () in the
> sockets as:
> 
> Send($remote_servername,"foo bar")
> 
> Instead of:
> 
> Send($remote_ip,"foo bar")
> 
> Always make associations based on name rather than IP.
> 
> Of course it means one would have to modify every stack out there, but
> things like skype etc could simply embed the method into their dlls etc when
> installed.
> 
> -----Original Message-----
> From: end2end-interest-bounces at postel.org
> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch
> Sent: Wednesday, February 22, 2006 4:38 AM
> To: Jon Crowcroft
> Cc: alok; end2end-interest at postel.org
> Subject: Re: [e2e] 100% NAT - a DoS proof internet
> 
> 
> 
> Jon Crowcroft wrote:
>>> glib.
>>>
>>> a nat could keep an algorithmic state variable but not maintain an
> externally detectable
>>> mapping from localt o globalraeachable adress (read my orignal email in
> this thread)
>>> OR
>>> it could keep state about actual e2e flows.
> 
> Sure.
> 
>>> completely different things 
> 
> Except that state is state ;-) I read the suggestion as "stateless", not
> "avoiding explicit per-connection state".
> 
> Joe