Subject: [midcom] RFC 3489 on STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

From: [email-masked]
Date: Thu, 20 Mar 2003 16:51:59 -0800

A new Request for Comments is now available in online RFC libraries.

        RFC 3489

        Title:      STUN - Simple Traversal of User Datagram Protocol
                    (UDP) Through Network Address Translators (NATs)
        Author(s):  J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy
        Status:     Standards Track
        Date:       March 2003
        Mailbox:    [email-masked],
                    [email-masked],
                    [email-masked], [email-masked]
        Pages:      47
        Characters: 117562
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-midcom-stun-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3489.txt

Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet.  It also provides the
ability for applications to determine the public Internet Protocol
(IP) addresses allocated to them by the NAT.  STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure.

This document is a product of the Middlebox Communication Working
Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Mar 2003 16:11:25 -0500

As you can see, STUN is now available as RFC 3489. There were a few 
changes during authors 48. The vast majority were clarifications. A few 
were bug fixes. THe most significant, which we discussed on the list, 
was the change back to 0x01 for the IPv4 address family:

Section 11.2.1, text after the figure:

OLD:

The port is a network byte ordered representation of the mapped port.
    The address family is always 0x02, corresponding to IPv4.

NEW:

The port is a network byte ordered representation of the mapped port.
    The address family is always 0x01, corresponding to IPv4.
                                 ^^^^

Here are the rest of the bug fixes that we sent:

Section 7, sixth paragraph:

OLD:

The seventh attribute, PASSWORD, is only found in Binding
    Response messages.

NEW:

The seventh attribute, PASSWORD, is only found in Shared Secret
                                                   ^^^^^^^^^^^^^
    Response messages.

Section 7, sixth paragraph:

OLD:

The ninth attribute is the ERROR-CODE attribute.  This is present in
    the Binding Error Response.

NEW:

The ninth attribute is the ERROR-CODE attribute.  This is present in
    the Binding Error Response and Shared Secret Error Response.
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 9.1 paragraph 3:

OLD:

For STUN requests, failure occurs if there is a transport failure of
    some sort (generally, due to fatal ICMP errors in UDP or connection
    failures in TCP).  Failure also occurs if the the request does not
    solicit a response after 30 seconds. If a failure occurs, the client
    SHOULD create a new request, which is identical to the previous, but
    has a different transaction ID. That request is sent to the next
    element in the list as specified by RFC 2782.

NEW (replace with):

For STUN requests, failure occurs if there is a transport failure of
    some sort (generally, due to fatal ICMP errors in UDP or connection
    failures in TCP).  Failure also occurs if the transaction fails due
    to timeout. This occurs 9.5 seconds after the first request is sent,
    for both Shared Secret Requests and Binding Requests.
    See Section 9.3 for details on transaction timeouts for Binding 
Requests. If a failure
    occurs, the client SHOULD create a new request, which is identical
    to the previous, but has a different transaction ID and MESSAGE
    INTEGRITY attribute (the HMAC will change because the transaction ID
    has changed). That request is sent to the next
    element in the list as specified by RFC 2782.

Section 9.2, paragpraph 4:

OLD:

Interpretation of
    those response codes is identical to the processing of Section 9.4
    for the Shared Secret Error Response.

NEW:

Interpretation of
    those response codes is identical to the processing of Section 9.4
    for the Binding Error Response.
            ^^^^^^^

Section 9.3, last paragraph:

OLD:

Retransmissions
    continue with intervals of 1.6s until a response is received, or a
    total of 9 requests have been sent, at which time the client SHOULD
    give up.

NEW (replace with):

Retransmissions continue with intervals of 1.6s until a response is 
received, or a total of 9 requests have been sent. If no response is 
received by 1.6 seconds after the last request has been sent, the client 
SHOULD consider the transaction to have failed. In other words, requests 
would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 
6300ms, and 7900ms. At 9500ms, the client considers the transaction to 
have failed if no response has been received.

Section 11.2.8:

OLD:

The text used as input to HMAC is the STUN message, including the
    header, up to and including the attribute preceding the MESSAGE-
    INTEGRITY attribute.

NEW:

The text used as input to HMAC is the STUN message, including the
    header, up to and including the attribute preceding the MESSAGE-
    INTEGRITY attribute. That text is then padded with zeroes so as to
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    be a multiple of 64 bytes.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 11.2.9 first paragraph:

OLD:

The ERROR-CODE attribute is present in the Binding Error Response and
    Shared Secret Error Response.  It is a numeric value in the range of
    100 to 699 plus a textual reason phrase, and is consistent in its

NEW:

The ERROR-CODE attribute is present in the Binding Error Response and
    Shared Secret Error Response.  It is a numeric value in the range of
    100 to 699 plus a textual reason phrase encoded in UTF-8, and is
                                            ^^^^^^^^^^^^^^^^
    consistent in its

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom