[p2p-hackers] Re: HTTP design flawed due to lack ofunderstandingofTCP

Scott C. Best sbest at best.com
Thu Jan 11 23:13:18 EST 2007


Alexander:

 	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?

thanks,
Scott


On Fri, 12 Jan 2007, Alexander Pevzner wrote:

> Scott,
>
> 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:
>> Alex:
>>
>>     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?
>>
>> cheers,
>> Scott
>>
>>
>> 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 mailing list