On Wed, Apr 8, 2009 at 8:02 PM, DaveThaler<dthaler@xxxxxxxxxxxxxxxxxxxxx> wrote: > On the topic of RESPONSE-TARGET, I completely agree with Cullen here... I couldn't follow from the current text, what the RESPONSE-TARGET was useful for that couldn't be done without it. I would prefer that it be either removed, or barring that, that it be better explained what it's needed for that can't be done without it. The requirement this introduces to keep state on the STUN server is undesirable in my view.> Dave, Thanks for the feedback (on other points as well). I wanted torespond to your and other people's feedback on XOR-RESPONSE-TARGET.In particular, there is an option for the state question that I wouldreally rather not add, but felt it is fair to bring it up as anoption. Numerous questions were brought up about what XOR-RESPONSE-TARGET isused for. I have ensured that every mention of it is coupled withbinding lifetime discovery through Section 5. The security requirements surrounding XOR-RESPONSE-TARGET have alsobeen clarified (and made consistent, since there were severalinconsistencies in the text since these requirements were debated andchanged in the evolution of the draft). The Security discussionsection sums this up: ---------------* The server MUST NOT respond to requests with XOR-RESPONSE-TARGETunless they have cached state that a binding request withCACHE-TIMEOUT has previously been received from the target address. * The server MUST either authenticate all requests usingXOR-RESPONSE-TARGET or rate-limit its responses to such requests.Rate-limiting is RECOMMENDED even if authenticating requests, unlessthe server is deployed for an application requiring more frequentresponses. * Requests containing both XOR-RESPONSE-TARGET and PADDING arerejected by the server. * Implementing XOR-RESPONSE-TARGET is optional, allowing servers thatcannot store the required state and/or deployed for applications thatdon't require its use to automatically reject any requests containingit.-------------- The decision of the working group was that rate limiting wassufficient to address security concerns since there is noamplification. The caching feature is additional protection, at theexpense of extra state. There had been no concern about the extrastate raised previously. (I agree that, in general, extra state isundesireable, but thememory requirements are only a few bytes per client transaction inprogress). Interestingly, 3489 had a shared-secret mechanism where the servercould essentially generate a magic cookie that the client had to usein subsequent requests. That mechanism could be used by a server toimplement this security without state since it could generate a cookiecombining a secret key with the client's source address and thenverify that the cookie matches when an XOR-RESPONSE-TARGET requestcomes in. But this support was removed in 5389. We could introduce a similar mechanism triggered by CACHE-TIMEOUT,etc, but I'm not convinced that the state saved here is worth theadditional protocol complexity. However, I wanted to bring up thisquestion for list discussion. Bruce_______________________________________________Ietf mailing listIetf@xxxxxxxxxxxxx://www.ietf.org/mailman/listinfo/ietf