[p2p-hackers] Re: HTTP design flawed due to lack
Scott C. Best
sbest at best.com
Thu Jan 11 23:13:18 EST 2007
Wow, that is surprising. How did you determine that A's mapping
got closed? I'm not sure that failing to contact it from Client-B is
sufficient proof: it would fail, for example, if A's router was actually
a port-restricting cone, rather than just an address-restricing one.
But maybe you tested it some other way?
On Fri, 12 Jan 2007, Alexander Pevzner wrote:
> not exactly. When router at A side receives ICMP message from router at
> B side, mapping at A side may get closed. If this situation is
> symmetric, you will not be able establish P2P link.
> This is not a theory, but real life situation.
> Scott C. Best wrote:
>> I think I may have misunderstood your advice. I was hoping to
>> clarify it by asking this way:
>> 1. Client-A transmits a UDP signal to the rendezvous server, creating
>> a mapping in A's restricted cone router.
>> 2. Client-B does this also, creating a mapping in its own router.
>> 3. The rendezvous server then provides client-A with client-B's external
>> address:port information, and provides client-B with client-A's.
>> 4. Client-A then opens a new socket and attempts to contact client-B
>> using the provided address:port information. This creates a second
>> mapping in A's restricted cone router.
>> At this point, I understood you to say that B's router will very
>> likely generate an ICMP port unreachable message. But, importantly, what
>> router mapping are you indicating gets "closed": the one client-B created
>> in step #2, the one client-A created in step #4, or both?
>> My understanding is that only the one in step #2 is at risk,
>> depending on the router vendor. Is that your understanding as well?
>> On Thu, 11 Jan 2007, Alexander Pevzner wrote:
>>> Scott C. Best wrote:
>>>> The idea we're looking into for echoWare is pretty simple: if
>>>> a rendezvous server can help determine a source-IP for a client, it
>>>> can be used to determine a source-Port as well. So when A contacts B,
>>>> it does so at the same UDP port that B used to contact the rendezvous
>>>> server, and so no ICMP port unreachable message is generated (though
>>>> a "stateful" firewall would/should prevent).
>>> Lets assume we are speaking about restricted cone routers - this is the
>>> most common case.
>>> Router at B side has mapping for packet, coming from server, but not
>>> from A. Depending on a router type, it may either send ICMP message or
>>> not (most likely, it will).
More information about the p2p-hackers