On Sat, Apr 4, 2009 at 6:22 PM, Christian Huitema
<huitema(_at_)windows(_dot_)microsoft(_dot_)com> wrote:
So most people miss this, which may mean it needs to be clarified more
somehow, but the algorithm section is actually not normative.
Maybe, but the draft starts with 20 pages of algorithm discussion, and
follows with 3 pages of attribute description. I would be much more
supportive if the draft could be summed up as "this draft defines 6 STUN
attributes and 2 response codes that can be used when characterizing the
attributes of NAT. It gives examples of possible algorithms that justify the
allocation of the attributes. It provides security guidelines that prevent
misuse of the attributes." You probably don't need more than 5-6 pages for
that.
Hmmm. I'm not sure what you're counting here. In -06 the algorithm
discussion runs from page 8 to 16 and the normative attribute and
behavior discussion runs from 16 to 24. The algorithm section used to
be shorter, but people kept asking for qualifiers and more precision
in what they did and didn't do. I'm really hesitant to shorten it
significantly given that it's as long as it is because people have
asked for it to be that long. I don't really think 8 pages is that
long, do you?
I believe the authentication and CACHE-TIMEOUT mechanisms in the draft
are sufficient for preventing DoS, and there was consensus for that
the last time the change was made and presented a few meetings ago,
but welcome any further comments on the issue.
Actually I have a comment there. The XOR-RESPONSE-TARGET attribute has a high
potential for abuse, since it allows clients to instruct servers to send
packets to arbitrary targets. I understand that requiring authentication
helps, but that leaves the door open for failures to implement authentication
properly in servers, or failures to secure credentials properly in clients.
Again, I would be much more supportive if this attribute definition was
removed from the draft.
In fact, I believe that XOR-RESPONSE-TARGET is not needed. Most of the tests
can be performed using the CHANGE-ADDRESS attribute, which does not have the
same potential for abuse. Besides, if you really want to send packets from
outside the local network towards arbitrary destinations, you can use TURN.
It's not possible to do any lifetime or other timeout tests without
XOR-RESPONSE-TARGET.
The CACHE-TIMEOUT mechanism prevents the attack you describe. It's
described at the beginning of Section 5 and in Section 7.8 among other
places. Group consensus was that since there is no amplification
attack, Section 7.8 only gives SHOULD level to requiring the server to
only respond to XOR-RESPONSE-TARGET when there is a current cached
request for the target address, and rate-limits XOR-RESPONSE-TARGET
when CACHE-TIMEOUT is not used. Obviously that decision is up for
debate, but there were conversations both on the mailing list and face
to face that led to the current text.
TURN is overkill for this application.
Bruce
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf