Subject: [BEHAVE] Determining NAT Filtering Behavior

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 13 Mar 2008 22:06:59 +0100

Hi

I have a question about draft-ietf-behave-nat-behavior-discovery-03 and
Determining NAT Filtering Behavior.

4.3.  Determining NAT Filtering Behavior

   <...>

   In test II, the client sends a binding request to the primary address
   of the server with the CHANGE-REQUEST attribute set to change-port
   and change-IP.  This will cause the server to send its response from
   its alternate IP address and alternate port.  <...>

I think rfc3489bis says that when sending a STUN Request to a server,
the STUN Response must follow the same flow back to the STUN Client.
Otherwise the response will be dropped.

A STUN Client is using the TID to match the transaction, and I guess
that it should also use the peer transport address. If that is the case
then the Filtering Behavior test will fail. Is there an exception
to the transaction matching, if the CHANGE-REQUEST attribute was present?

/alfred

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Wed, 19 Mar 2008 10:14:43 -0400

> to the transaction matching, if the CHANGE-REQUEST attribute was  

Hmmm.   It seems that CHANGE-REQUEST processing is inconsistent with  
section 7.3.1.2 of STUNbis:

    The response (success or error) is sent over the same transport as
    the request was received on.  If the request was received over UDP,
    the destination IP address and port of the response is the source IP
    address and port of the received request message, and the source IP
    address and port of the response is equal to the destination IP
    address and port of the received request message.  If the request  
was
    received over TCP or TLS-over-TCP, the response is sent back on the
    same TCP connection as the request was received on.

However, I don't see anywhere in STUNbis that says that a client  
should use the peer transport address when matching responses with  
requests (though I also don't see any text that says explicitly that  
it should just use transaction ids). If you think there is, can you  
point it out? For anything other than Behavior-Discovery, it is  
immaterial which way this is implemented.

Personally, I would be tempted to fix this by having draft-ietf- 
behave-nat-behavior-discovery override the base STUNbis spec, because  
I could imagine defining future tests that would do other weird  
things not expected by STUNbis. However, I will let Jonathan (who is  
the STUNbis editor) and the draft-ietf-behave-nat-behavior-discovery  
authors sort this out.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Mar 2008 16:12:47 -0700

Philip wrote:
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Matthews
> Sent: Wednesday, March 19, 2008 7:15 AM
> To: Alfred E. Heggestad
> Cc: Behave WG
> Subject: Re: [BEHAVE] Determining NAT Filtering Behavior
> 
> 
> > I have a question about 
> > draft-ietf-behave-nat-behavior-discovery-03 and
>     address and port of the received request message.  If the 
>     request was
> it should just use transaction ids). 

draft-ietf-behave-rfc3489bis-15, bottom of page 6:

  For request/response transactions, this transaction ID allows 
  the client to associate the response with the request that 
  generated it; for indications, this serves as a debugging aid. 

-d

> If you think there is, can you

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 21 Mar 2008 17:58:37 +0100

>   generated it; for indications, this serves as a debugging aid. 

so what you are saying is that, by default, the STUN Client
does not check the source address of the STUN Response.

But it can be overridden by the usage, like e.g. ICE:

7.1.2.2.  Success Cases

   A check is considered to be a success if all of the following are
   true:

   o  the STUN transaction generated a success response

   o  the source IP address and port of the response equals the
      destination IP address and port that the Binding Request was sent
      to

   o  the destination IP address and port of the response match the
      source IP address and port that the Binding Request was sent from

Is is specified in the TURN-07 draft that the TURN client should check
the source address of any STUN Response, btw?

/alfred

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 21 Mar 2008 10:08:10 -0700

> does not check the source address of the STUN Response.

I didn't see text in rfc3489bis that said the port of the response
needed to be checked.  I believe behavior-discovery needs to
send response packets from different ports and from different
IP addresses in order to do some of its checks.

>       source IP address and port that the Binding Request was 

Right.

> the source address of any STUN Response, btw?

I don't believe so.

But, considering that TURN is most often used when the TURN client
is behind a 'symmetric' NAT, the TURN server needs to be very careful
and send the STUN Response using the source IP address of the STUN
request.  Otherwise, the TURN server's response will not get through
the symmetric NAT at all.

-d