Subject: Re: [midcom] STUN issues - Processing Binding Response clarification

From: "Panayiotis A. Thermos" <[email-masked]>
Date: Mon, 9 Dec 2002 12:41:14 -0500

Jonathan thanks for the reply,

my comments were based on the following version
http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt
which I assume is the latest draft, unless I missed the announcement
of newer drafts.

If so, which one is the latest one, and how I can keep track of the new
releases?
Although I believe I follow the mailing list closely, I haven't seen any
announcements for
new versions. Unless they were communicated over another channel.

Thanks again for your time and help.

                    Jonathan                                                                             
                    Rosenberg              To:     "Panayiotis A. Thermos" <[email-masked]>      
                    <jdrosen@dynami        cc:     [email-masked], (bcc: Panayiotis A.                  
                    csoft.com>             Thermos/Telcordia)                                            
                                           Subject:     Re: [midcom] STUN issues - Processing Binding    
                    12/09/2002             Response clarification                                        
                    12:08 PM                                                                             

Sorry I never responded to this. Response inline.

Panayiotis A. Thermos wrote:
> Greetings to all.
>
> I apologize if this has been discussed before.
>
> The draft states the following (section 9.4-Processing Binding Responses,
> page 18, third paragraph )
>
> "   If the response is a Binding Response, the client SHOULD check the
>    response for a MESSAGE-INTEGRITY attribute. If not present, and the
>    client placed a MESSAGE-INTEGRITY attribute into the request, it MUST
>    discard the response."
>
> In the case where the client sends a binding "change-IP" and
"change-port"
> request with a MESSAGE-INTEGRITY
> attribute, the server (e.g. server A) will forward the request to another
> STUN server (e.g. server B) which in turn will
> respond to the client's request.

That particular methodology was found problematic and was removed from
the spec several revisions back.

>The later server (B) may not include a
> MESSAGE-INTEGRITY attribute in it's response
> thus the client will discard the response. And even if server B includes
a
> MESSAGE-INTEGRITY attribute, it will be wrong
> and thus the client will discard the response.

Right, precisely the kind of reason why this method for implementing
change IP has been removed. The spec details a different approach now,
in Section 8.1.

>
> Perhaps the draft should incorporate that STUN server A should notify
> server B not to calculate its own SHA1 but use
> server's A MESSAGE-INTEGRITY attribute instead in this case. The
> notifications can be done through the FLAGS attribute
> (e.g. a re-use attribute flag "REUSE-ATTRIBUTE" with value
> "MESSAGE-INTEGRITY").

As above, since this mechanism has been removed, there is no need for
these changes.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Dec 2002 12:41:51 -0500

> which I assume is the latest draft, unless I missed the announcement

-03 is the current one. I am finishing up -04 right now. However, the 
usage of a second server for sending the response was removed as of 
draft-ietf-midcom-00.

-Jonathan R.