3.1.5.2.2 Validating the STUN Binding Request

The validation procedures for Simple Traversal of UDP through NAT (STUN) binding request messages as specified in [IETFDRAFT-STUN-02] section 8 differ from the procedures described in this section. Endpoints that follow this protocol MUST follow the procedures in this section to validate the STUN binding request messages that are received for connectivity checks.

If a STUN binding request message is received without a USERNAME attribute, the STUN binding request message MUST be discarded. ICE keep-alive messages are discarded if they do not have the USERNAME attribute. If the USERNAME attribute is not valid, the message MUST be discarded. A USERNAME attribute is considered valid if it consists of two values separated by a colon and the first value equals the username fragment generated by the endpoint in the offer. If the received STUN binding request message does not have the fingerprint attribute, the message MUST be discarded. If the STUN binding request message does not have the MESSAGE-INTEGRITY attribute, the endpoint MUST send a binding error response with error code 401 (Unauthorized), as specified in [IETFDRAFT-STUN-02] section 8. If the MESSAGE-INTEGRITY attribute exists, the endpoint MUST use the STUN short-term credential mechanism, by using the password that was sent to the peer to compute the message integrity, and verify against the message integrity value in the request. If the message integrity check fails, the endpoint MUST send a binding error response with error code 431 (Integrity Check Failure), as specified in [IETFDRAFT-STUN-02] section 8. Generated binding error responses MUST have a USERNAME attribute set to the value of the USERNAME attribute received in the STUN binding request message.