Subject: [Ietf-behave] Compatibility between RFC3489 and draft-ietf-behave-rfc3489bis-04

From: "Alfred E. Heggestad" <[email-masked]>
Date: Tue, 3 Oct 2006 09:32:32 -0500 (CDT) (envelope-from [email-masked])

Hi

Is rfc3489bis-04 intended to be backwards compatible with RFC3489? i.e. should
it be possible to use a RFC3489 compliant STUN-client with a bis-04 compliant
STUN server, or vice versa?

My findings so far, when implementing a STUN library as specified in 
rfc3489bis-04,
is that there are some issues. However they might be implementation-specific.

* rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN server:

  The STUN request contains the new FINGERPRINT attribute, but this
  attribute is not supported by the STUN server (Vovida.org 0.96),
  hence the response is dropped.

* RFC3489-compliant STUN client against rfc3489bit-04 compliant STUN server:

  The STUN request is sent from the client (X-lite) and the STUN server
  returns a response with MAPPED-ADDRESS attribute. But since the response
  does not contain attributes SOURCE-ADDRESS and CHANGED-ADDRESS, the STUN
  client is not able to use the response.

If these two specs are intended to be compliant, are there any special
ways of getting this to work?

many thanks in advance.

/alfred

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Oct 2006 10:44:24 -0500 (CDT) (envelope-from [email-masked])

> Is rfc3489bis-04 intended to be backwards compatible with RFC3489?
> I.E. should it be possible to use a RFC3489 compliant STUN-client
> with a bis-04 compliant STUN server, or vice versa?
>
> rfc3489bis-04, is that there are some issues.  However they might be
> implementation-specific.
> 
> 

That shouldn't be a problem for the RFC3489bis-compliant STUN client.  The
primary purpose of this attribute is to provide an additional distinguisher
for STUN/non-STUN packets.  That is, there isn't any reason for an
RFC3489bis-compliant STUN server to validate or check for that attribute.
Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a RFC3489
STUN server won't return it.  Thus, if the RFC3489bis client wants to
interoperate with a RFC3489 STUN server, it needs to understand the
responses sent by a RFC3489 server.

>    The STUN request is sent from the client (X-lite) and the STUN
>    server returns a response with MAPPED-ADDRESS attribute.  But
>    since the response does not contain attributes SOURCE-ADDRESS and
>    CHANGED-ADDRESS, the STUN client is not able to use the response.

You probably noticed that in RFC3489 the transaction ID is 128 bits but in
RFC3489bis the same bits in the STUN packet are the fixed magic cookie (32
bits) and a 96 bit transaction ID.  Your RFC3489bis-compliant STUN server
can determine if the incoming STUN request was sent by a RFC3489-compliant
STUN client or an RFC3489-bis-compliant STUN server by examining the 32 bit
value.  If it's 0x2112A442 (the value of the magic cookie in RFC3489bis),
the STUN request is from a RFC3489bis client; if it's some other value, the
STUN request is from a RFC3489 client.

-d

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Tue, 3 Oct 2006 18:32:09 -0500 (CDT) (envelope-from [email-masked])

Dan Wing wrote:

* rfc3489bis-04 compliant STUN client against 
RFC3489-compliant STUN server:

many thanks for your answer. ok I understand that the new FINGERPRINT
attribute to distinguish between STUN and non-STUN packets.

prior to sending a STUN request, the STUN client cannot know which
version of the spec the STUN server supports. so it can e.g. try to
send a bis-04 compliant STUN request include the FINGERPRINT attrib
and if it times out, then try to send a STUN request ala RFC3489..

* RFC3489-compliant STUN client against rfc3489bit-04 
compliant STUN server:

yes you are right. I have updated my STUN server now to support both
flavours. although there is a (tiny) chance that the first 4 bytes
of the TID generated by a RFC3489-client actually contains 0x2112a442.

but I guess, if the a STUN request fails for this reason the client
will just retry until it works..

thanks again for your help.

/alfred

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Oct 2006 05:49:22 -0500 (CDT) (envelope-from [email-masked])

I think it is important to recognize that some aspects of rfc3489bis  
are still

under discussion and may change significantly. For example, the
FINGERPRINT attribute was introduced in the -04 version and was
the subject of much discussion at the last meeting. If you are  
interested,

you can read the minutes of the last BEHAVE meeting in the Proceedings
portion of the IETF website.

- Philip

On 3-Oct-06, at 19:32 , Alfred E. Heggestad wrote:

Dan Wing wrote:

That shouldn't be a problem for the RFC3489bis-compliant STUN  
client.  The
primary purpose of this attribute is to provide an additional  
distinguisher

for STUN/non-STUN packets.  That is, there isn't any reason for an
RFC3489bis-compliant STUN server to validate or check for that  
attribute.
Similarly, it won't see the XOR-MAPPED-ADDRESS, either, because a  
RFC3489

You probably noticed that in RFC3489 the transaction ID is 128  
bits but in
RFC3489bis the same bits in the STUN packet are the fixed magic  
cookie (32
bits) and a 96 bit transaction ID.  Your RFC3489bis-compliant STUN  
server
can determine if the incoming STUN request was sent by a RFC3489- 
compliant
STUN client or an RFC3489-bis-compliant STUN server by examining  
the 32 bit
value.  If it's 0x2112A442 (the value of the magic cookie in  
RFC3489bis),
the STUN request is from a RFC3489bis client; if it's some other  
value, the

/alfred

---

From: <[email-masked]>
Date: Thu, 5 Oct 2006 03:00:59 -0500 (CDT) (envelope-from [email-masked])

Hi,

There are some non backwards compatible issues in rfc3489bis-04 in the
STUN service discovery.
You can see these by looking at the Behave WG mailing list archive - the
mail subject is "STUN Server Discovery".
IMHO, these compatibility issues have not yet been solved.
I hope these are taken thoroughly care of in the next draft version.

--
Tomi Kohonen
Nokia Corporation

>-----Original Message-----
>From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
>ext Alfred E. Heggestad
>Sent: 03 October, 2006 17:32
>To: ietf-behave@xxxxxxxxxxxxxxxxxxx
>Subject: [Ietf-behave] Compatibility between RFC3489 
>anddraft-ietf-behave-rfc3489bis-04
>
>Hi
>
>Is rfc3489bis-04 intended to be backwards compatible with 
>RFC3489? i.e. should it be possible to use a RFC3489 compliant 
>STUN-client with a bis-04 compliant STUN server, or vice versa?
>
>My findings so far, when implementing a STUN library as 
>specified in rfc3489bis-04, is that there are some issues. 
>However they might be implementation-specific.
>
>
>If these two specs are intended to be compliant, are there any 
>special ways of getting this to work?
>
>many thanks in advance.
>
>
>/alfred
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Oct 2006 15:32:22 -0500 (CDT) (envelope-from [email-masked])

inline.

Alfred E. Heggestad wrote:

Dan Wing wrote:

Actually I have a better idea. I can change the value of FINGERPRINT to 
be in the range of optional attributes. This way, it will be ignored by 
an older RFC3489 implementation. Since muxing is not an issue in the 
classic rfc3489 stun usage, its fine.

It will be really, really rare. Given a packet loss of 10%, its actually 
more likely that all of teh requests in a transaction are lost than it 
is you'll run into this overlap.

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sun, 15 Oct 2006 06:23:38 -0500 (CDT) (envelope-from [email-masked])

inline.

Jonathan Rosenberg wrote:

inline.

Dan Wing wrote:

* rfc3489bis-04 compliant STUN client against RFC3489-compliant STUN 
server:

yes, that makes sense. the FINGERPRINT (or CRC32) attribute could be
optional, but RECOMMENDED for checking the validity of a STUN message.
the STUN server will always include this attribute for responses
to rfc3489bis clients.

ok fair enough..

/alfred

Thanks,
Jonathan R.