Subject: [midcom] Scott Bradner: response from the IESG on stun 04

From: Melinda Shore <[email-masked]>
Date: Sun, 15 Dec 2002 11:59:30 -0500

Feedback on the most recent STUN draft - we're still in the
woods on several issues.

Melnda

------- Forwarded Message

Date:    Sat, 14 Dec 2002 09:36:34 -0500
From:    Scott Bradner <[email-masked]>
To:      [email-masked]
Subject: response from the IESG on stun 04

to be shared with the list

- ----

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Dec 2002 17:22:33 -0500

some responses inline.

Melinda Shore wrote:

 >>8.2 Shared Secret Requests
 >>
 >>[...snip...]
 >>
 >>   If the server receives a Shared Secret Request, it MUST verify that
 >>   the request arrived on a TLS connection. If not, it discards the
 >>   request.
 >>
 >>[...snip...]
 >>
 >>9.1 Discovery
 >>
 >>[...snip...]
 >>
 >>   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.
 >
 >
 > I still don't understand why not an error code is sent back in 8.2.

There are two STUN requests, the Binding Request and Shared Secret
Request. I added responses for the Binding Request in all cases, basd on
your comments, so that there is no retransmitted requests or confusion
on the part of the client.

For Shared Secret Requests (the case of 8.2), those requests MUST always
be sent by a client over TLS. Thus, the case of receiving them over
something besides TLS should never happen in a correct implementation.
THus, an error response which basically says "your software is wrong"
probably won't help. However, it can't hurt, and since it may stop
retransmissions, it is worth adding.

The text in 8.2 now reads:

> If the server receives a Shared Secret Request, it MUST verify that
> the request arrived on a TLS connection. If not, it MUST generate a
> Shared Secret Error Response, and it MUST include an ERROR-CODE
> attribute with a 433 response code. If the Shared Secret Request was
> received over TCP, the Shared Secret Error Response
> is sent over the same connection the request was received on. If the
> Shared Secret Request was receive over UDP, the Shared Secret Error
> Response is sent to the source IP address and port that the request
> came from.

 >>(5) The end of this paragraph is weird.
 >>
 >>11.2 Message Attributes
 >>
 >>[...snip...]
 >>
 >>   Future extensions MAY define new attributes. If a STUN client or
 >>   server receives a message with an unknown attribute with a type
 >>lower
 >>   than or equal to 0x7fff, the message MUST be discarded. If the type
 >>   is greater than 0x7fff, the attribute MUST be ignored. The ordering
 >>   of attributes within a message is not important (except that the
 >>   MESSAGE-INTEGRITY attribute MUST be the last attribute), and a
 >>client
 >
 >
 > The new paragraph is more weird now. I don't know what this means to an
 > implementation:
 >
 >
 >>   Extensions, documented in standards track IETF RFCs, MAY define new
 >>   attributes. Attributes with values greater than 0x7fff are optional,
 >>   and those less than or equal to 0x7fff are mandatory to understand.
 >
 >
 > "mandatory to understand"? Especially for codes which will be
 > registered later.

Detailed semantics for this are provided in section 8.1, which has this 
to say for binding requests:

>  The server MUST check for any attributes in the request with values
>    less than or equal to 0x7fff which it does not understand. If it
>    encounters any, the server MUST generate a Binding Error Response,
>    and it MUST include an ERROR-CODE attribute with a 420 response code.
>    That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing
>    the attributes with values less than or equal to 0x7fff which were
>    not understood. The Binding Error Response is sent to the IP address
>    and port the Binding Request came from, and sent from the IP address
>    and port the Binding Request was sent to.

and 8.2 for shared secret requests:

> The server MUST check for any attributes in the request with values
>    less than or equal to 0x7fff which it does not understand. If it
>    encounters any, the server MUST generate a Shared Secret Error
>    Response, and it MUST include an ERROR-CODE attribute with a 420
>    response code. That response MUST contain an UNKNOWN-ATTRIBUTES
>    attribute listing the attributes with values less than or equal to
>    0x7fff which were not understood. The Shared Secret Error Response is
>    sent over the TLS connection.

and 9.2 for shared secret responses:

> If a client receives a Shared Secret Response with an attribute whose
>    type is greater than 0x7fff, the attribute MUST be ignored. If the
>    client receives a Shared Secret Response with an attribute whose type
>    is less than or equal to 0x7fff, the response is ignored.

and 9.4 for binding responses:

> If a client receives a response with an attribute whose type is
>    greater than 0x7fff, the attribute MUST be ignored. If the client
>    receives a response with an attribute whose type is less than or
>    equal to 0x7fff, request retransmissions MUST cease, but the entire
>    response is otherwise ignored.

However, I will further clarify the text in the paragraph you point out. 
  It now reads:

> Extensions, documented in standards track IETF RFCs, MAY define new
> attributes. Attributes with values greater than 0x7fff are optional,
> which means that the message can be processed by the client or server
> even though the attribute is not understood. Attributes with values
> less than or equal to 0x7fff are mandatory to understand, which means
> that the client or server cannot process the message unless it
> understands the attribute.

 >>13 IANA Considerations
 >>
 >>   There are no IANA considerations associated with this specification.
 >
 >
 > I still think we have a registration issue here. Both regarding flags
 > and extensions. Especially together with "mandatory to understand".

To be clear, I have removed flag extensibility altogether (in fact, the 
attribute is no longer named FLAGS). SO, its just attributes. Anyway, 
the idea is that since we don't anticipate extensions, an IANA registry 
need not be set up at this time. However, if we do get any, we can 
create the registries at that time. I would propose the following new 
text for IANA considerations:

> STUN can be extended by defining new attributes in standards track
> extensions. However, since it is anticipated that no extensions will
> be needed or defined, no IANA registry is to be created at this
> time. Should an extension to STUN be defined, that extension can
> establish any necessary registries.

Do these changes address your concerns?

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