Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5780 (2939)

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Sep 2011 00:44:46 -0400

It sounds like we should proceed to verify this errata and follow
Bruce's suggestion to delete the offending text.  In the notes we
could also include a bit of the rationale that's been shared on the
list here.

If there are no objections, I'll go ahead and do this.

On 8/27/2011 5:15 PM, Bruce Lowekamp wrote:
> On Tue, Aug 23, 2011 at 2:16 PM, John Selbie<[email-masked]>  wrote:
>> Could a STUN server could be selective about using either based on the
>> client request type?  If the client request is missing the stun magic
>> cookie, then it could be assumed to be written to rfc 3489.  As such the
>> server sends back the legacy CHANGED-ADDRESS attribute. Otherwise send back
>> OTHER-ADDRESS if the client request contains the stun magic cookie.  Or just
>> send both?  Would that be permissible?
>
> Yes, one intention was that if you wanted to, you could distinguish
> between the two protocols using the magic cookie.
>
>
>> Can you elaborate on why it was "deliberately renumbered to break
>> compatibility with 3489" ?  As I read the behavior for handling
>> "change-request" and calculating the "other address" as described in both
>> 3489 (section 8.1) and 5780 (section 6.1) the text appear to be near
>> identical in description.  That is, the stun response always contains an
>> attribute containing the other IP and other port opposite from which the
>> request arrived on?  Yes?  Or is there some subtle difference I'm missing?
>
> The desire to break compatibility had more to do with the intended
> (and described) uses of 3489 than with this actual aspect of the
> protocol.  The intention was to ensure that applications written with
> 3489's characterization approach hard-coded be updated to reflect how
> to use ICE, etc for NAT traversal, even if they applied some of the
> same techniques that are now in 5780 for appropriate reasons.
>
>> Is there an email exchange discussion for STUN, TURN, and NAT traversal?
>
> STUN and TURN came from behave, so I guess it's still good to discuss them here.
>
> Bruce
>
>
>>
>> jrs
>>
>>
>> On Wed, Aug 17, 2011 at 9:32 PM, Bruce Lowekamp<[email-masked]>  wrote:
>>>
>>> Wow, this one really surprises me.  We made that change in the -02
>>> draft and somehow missed that paragraph the entire time after.
>>>
>>> Looking back on my slides from the change, I believe the paragraph in 7.4:
>>>
>>>    OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
>>>    RFC 3489 [RFC3489] because it is simply a new name with the same
>>>    semantics as CHANGED-ADDRESS.  It has been renamed to more clearly
>>>    indicate its function.
>>>
>>> should be deleted in its entirety.  It was deliberately renumbered to
>>> break compatibility with 3489 clients.
>>>
>>> Bruce
>>>
>>> On Wed, Aug 17, 2011 at 3:42 PM, RFC Errata System
>>> <[email-masked]>  wrote:
>>>>
>>>> The following errata report has been submitted for RFC5780,
>>>> "NAT Behavior Discovery Using Session Traversal Utilities for NAT
>>>> (STUN)".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=5780&eid=2939
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: John Selbie<[email-masked]>
>>>>
>>>> Section: 9.1
>>>>
>>>> Original Text
>>>> -------------
>>>> Section 9.1
>>>>    ...
>>>>    0x802c: OTHER-ADDRESS
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>>
>>>>
>>>> Notes
>>>> -----
>>>> Section 7.4 of RFC 5780 states: "OTHER-ADDRESS uses the same attribute
>>>> number as CHANGED-ADDRESS from RFC 3489". (Defined as 0x0005 in rfc 3489).
>>>>
>>>> But section 9.1 of RFC 5780 defines the value of OTHER-ADDRESS as being
>>>> 0x802c.
>>>>
>>>> Suggestion: Either update section 7.4 to not reference RFC 3489 or
>>>> update the STUN attribute registry such that OTHER-ADDRESS remains at
>>>> 0x0005.
>>>>
>>>> Instructions:
>>>> -------------
>>>> This errata is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC5780 (draft-ietf-behave-nat-behavior-discovery-08)
>>>> --------------------------------------
>>>> Title               : NAT Behavior Discovery Using Session Traversal
>>>> Utilities for NAT (STUN)
>>>> Publication Date    : May 2010
>>>> Author(s)           : D. MacDonald, B. Lowekamp
>>>> Category            : EXPERIMENTAL
>>>> Source              : Behavior Engineering for Hindrance Avoidance
>>>> Area                : Transport
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>
>>
>>
>
>

-- 
Wes Eddy
MTI Systems