On Wed, Apr 8, 2009 at 8:02 PM, Dave
Thaler<dthaler(_at_)windows(_dot_)microsoft(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf