Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04

Dan Wing wrote:
>>
>> * 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.
> 
> 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.
> 

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:
>>
>>    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.
> 

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


_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

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:
>>>
>>> * 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.
>>
>> 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.
>>
>
> 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:
>>>
>>>    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.
>>
>
> 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
>
>
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behavelist.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave


_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

inline.

Alfred E. Heggestad wrote:

> Dan Wing wrote:
> 
>>>* 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.
>>
>>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.
>>
> 
> 
> 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..

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.


> 
> 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..

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
jdrosencisco.com                              FAX:   (973)
952-5050
http://www.jdrosen.net 
                       PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

inline.

Jonathan Rosenberg wrote:
> inline.
> 
> Alfred E. Heggestad wrote:
> 
>> Dan Wing wrote:
>>
>>>> * 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.
>>>
>>> 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.
>>>
>>
>>
>> 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..
> 
> 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.
> 

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.



> 
>>
>> 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..
> 
> 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.
> 

ok fair enough..



/alfred

> Thanks,
> Jonathan R.
> 
> 

_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave