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.
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.
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf