On Wed, Apr 8, 2009 at 8:02 PM, Dave Thaler<[email protected]> 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 to respond to your and other people's feedback on XOR-RESPONSE-TARGET. In particular, there is an option for the state question that I would really rather not add, but felt it is fair to bring it up as an option. Numerous questions were brought up about what XOR-RESPONSE-TARGET is used for. I have ensured that every mention of it is coupled with binding lifetime discovery through Section 5. The security requirements surrounding XOR-RESPONSE-TARGET have also been clarified (and made consistent, since there were several inconsistencies in the text since these requirements were debated and changed in the evolution of the draft). The Security discussion section sums this up: --------------- * The server MUST NOT respond to requests with XOR-RESPONSE-TARGET unless they have cached state that a binding request with CACHE-TIMEOUT has previously been received from the target address. * The server MUST either authenticate all requests using XOR-RESPONSE-TARGET or rate-limit its responses to such requests. Rate-limiting is RECOMMENDED even if authenticating requests, unless the server is deployed for an application requiring more frequent responses. * Requests containing both XOR-RESPONSE-TARGET and PADDING are rejected by the server. * Implementing XOR-RESPONSE-TARGET is optional, allowing servers that cannot store the required state and/or deployed for applications that don't require its use to automatically reject any requests containing it. -------------- The decision of the working group was that rate limiting was sufficient to address security concerns since there is no amplification. The caching feature is additional protection, at the expense of extra state. There had been no concern about the extra state raised previously. (I agree that, in general, extra state is undesireable, but the memory requirements are only a few bytes per client transaction in progress). Interestingly, 3489 had a shared-secret mechanism where the server could essentially generate a magic cookie that the client had to use in subsequent requests. That mechanism could be used by a server to implement this security without state since it could generate a cookie combining a secret key with the client's source address and then verify that the cookie matches when an XOR-RESPONSE-TARGET request comes 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 the additional protocol complexity. However, I wanted to bring up this question for list discussion. Bruce _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
