[e2e] using p2p overlays to overcome recursive NATs/realms

[David P. Reed]

Regarding recent middlebox problems.  The STSN (hotel) network spoofs all 
SMTP traffic directing it to its own SMTP service instead.  When STSN 
provided a shared connection for a conference here in Pasadena, its 
spoofing managed to get totally confused, so 50 people sharing a router 
could not send email, though they could do everything else.  Completely 
non-obvious what was happening, and a lot of time was wasted by all.

Of course if STSN gets on the bad side of the email blackholers, suddenly 
all hotel guests will be forced to try to figure out why only the mail that 
they send from hotels disappears without a trace into the blackholers 
bitbucket.

There oughta be a law...  I don't know which is worse - STSN doing this or 
the blackholers.
At 07:32 AM 2/8/2002 -0800, Joe Touch wrote:
>Jon Crowcroft wrote:
>
>>so the problem with most the proposed solutions to workign around nats
>>is that they really assume there are only 2 realms - the great unwashed 
>>internet, and the poor deprived natted user.
>>the real situation is that packets might traverse multiple natted realms 
>>(c.f. realm
>>specific ip) - in this scenario, discovering the mapping involves 
>>discovering a path of
>>several mappings-
>>soluton might be to start a p2p service, which propgates mappings - take 
>>the ideas from
>>stun, turn, rsip etc, and use them repeatedly...where multicast is 
>>available use it
>
>
>Why replace one broken system (NATs) with another (P2Ps)?
>
>The former breaks access to servers (behind NATs) - servers like automated 
>configuration management (as deployed by Compaq, e.g.), MS Netmeting and 
>other conferencing and telephony apps, gaming, etc.
>
>The latter replicates Internet routing outside the network layer, 
>potentially creating inefficient redundant traversals over congested links.
>
>BTW, I've been hit by NATs twice in the past week -
>
>1) at Stanford Univ at a workshop, where wireless service behind a NAT 
>defeated (unclear as yet as to how) PPTP tunneling. The connection would 
>get about halfway there, and die. The site administrators kept asserting 
>their NAT box wasn't the issue; wired connections at the same site worked 
>fine. One wonders how much money is being wasted debugging errors created 
>by NATs.
>
>2) SMC and Linksys sell what they both call "wireless Internet DSL 
>routers". Sadly, they do just about everything _except_ route. They are 
>NAT boxes, and their NAT function cannot be disabled.
>
>The interesting question is why. Bridging is a much simpler function, and 
>there are quite a few advanced features that require substantial network 
>expertise.
>
>Anywho, can't we all just speak IP? :-)
>
>Joe
>
>