Subject: [BEHAVE] Error code for unsupported method

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Apr 2008 09:23:16 -0400

Hello,

What is a STUN server supposed to use as error code when an unknown method is 
received? From the list in 3489bis, Section 15.6, I'd be tempted to pick 
either 400 or 500, depending on who I'm siding with, but this doesn't seem 
right because it's really nobody's fault.

Will people crucify me if I return a 501 Not Implemented, as in HTTP?

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 24 Apr 2008 16:53:59 +0300

Le Thursday 24 April 2008 16:23:16 ext Simon Perreault, vous avez écrit :
> Hello,
>
> What is a STUN server supposed to use as error code when an unknown method
> is received? From the list in 3489bis, Section 15.6, I'd be tempted to pick

Yes they will. Sending a 5xx error code allows the client to retry the request 
a certain number of times, hence it is only appropriate for transitional 
errors.

You should rather use 400 Bad Request, for lack of a more precise value in the 
4xx range. Unknown request types can only occur if a client tries to contact 
a server for an inappropriate "usage" of STUN. So in a sense, the request is 
malformed.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Thu, 24 Apr 2008 14:56:24 -0400

> Will people crucify me if I return a 501 Not Implemented, as in HTTP?

Section 7.3 of draft-ietf-behave-rfc3489bis-15 says (second paragraph):

    When a STUN agent receives a STUN message, it first checks that the
    message obeys the rules of Section 6.  It checks that the first two
    bits are 0, that the magic cookie field has the correct value, that
    the message length is sensible, and that the method value is a
    supported method.  If the message-class is Success Response or Error
    Response, the agent checks that the transaction ID matches a
    transaction that is still in progress.  If the FINGERPRINT extension
    is being used, the agent checks that the FINGERPRINT attribute is
    present and contains the correct value.  If any errors are detected,
    the message is silently discarded.  In the case when STUN is being
    multiplexed with another protocol, an error may indicate that this  
is
    not really a STUN message; in this case, the agent should try to
    parse the message as a different protocol.

Thus an implementation should silently discard an unsupported method.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Apr 2008 15:57:34 -0700

At Thu, 24 Apr 2008 14:56:24 -0400,
Philip Matthews wrote:
At Thu, 24 Apr 2008 14:56:24 -0400,
> Thus an implementation should silently discard an unsupported method.

Wow. I totally never noticed this. 

So, I get the reasoning for silent discards for cases where we're not
sure that this is STUN or not, but if everything but the method looks
right, wouldn't it make more sense to send an error?

-Ekr

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Apr 2008 19:02:01 -0400

> right, wouldn't it make more sense to send an error?

+1

---

From: Philip Matthews <[email-masked]>
Date: Thu, 24 Apr 2008 22:48:46 -0400

> right, wouldn't it make more sense to send an error?

Perhaps.
It would certainly allow the client to more rapidly detect that the  
server doesn't support a particular method, since right now the client  
has to wait the 40 second timeout period to be certain.
However, I vaguely remember thinking when I wrote the above text, that  
there were cases where a silent discard was desirable. Unfortunately,  
I cannot remember any right now. (And, when I wrote the text, the  
timeout period was 10 seconds, not 40...)

- Philip

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 25 Apr 2008 10:25:25 -0400

It seems like the intention should be something along the lines of  
(merging in a clarification from the duplicate request handling issue):

When a STUN agent receives a STUN message, it first checks that the    
message obeys the rules of Section 6.  It checks that the first two    
bits are 0, that the magic cookie field has the correct value, and  
that   the message length is sensible.  If the FINGERPRINT  
extension   is being used, the agent checks that the FINGERPRINT  
attribute is   present and contains the correct value.  If any of  
these conditions are not met, the message is silently discarded or,  
in the case when STUN is being   multiplexed with another protocol,   
the agent should try to   parse the message as a different protocol.

If the message-class is Success Response or Error   Response, the  
agent checks that the transaction ID matches a   transaction that is  
still in progress.   If the transaction ID does not match an in- 
progress transaction, the response is silently discarded.

Then move the case of the unknown method check to 7.3.1 and return a  
400 (actually, I think a new error response would be appropriate here).

Actually, I think there's a bizarre pathological case here.  I don't  
see a specification that Is there a requirement anywhere in the  
protocol that the UAC must check that the method in a response  
matches the method in the request.  So possibly the above tid check  
should also check that the method matches the original request.

Bruce

---

From: Philip Matthews <[email-masked]>
Date: Fri, 25 Apr 2008 10:49:47 -0400

I am not the editor of ietf-behave-rfc3489bis.

However, if I was the editor, I would ask:
1) Is this an important enough change to modify a document that is  
almost through IESG processing (and which has TWICE gone through WGLC)?
2) What do existing deployed STUN servers do today?

Unlike the proposed new CLIENT attribute, this proposed change does  
not add any new functionality, but just gives faster recovery from an  
error case.

How many people think that a change along the lines that Bruce  
sketched below is important?

- Philip

PS. I agree that, _if_ we were to make this change, a new error code  
would be appropriate.
PPS. I also agree that a client implemented using defensive  
programming techniques should confirm that the method in the response  
matches that in the request, even though the match on the transaction  
id should guarantee this.
PPPS. And I still wonder if there are not cases where we want a silent  
drop, and not an error response.

On Fri, 25-Apr-08, at 10:25 , Bruce Lowekamp wrote:
> When a STUN agent receives a STUN message, it first checks that  
> the   message obeys the rules of Section 6.  It checks that the  
> first two   bits are 0, that the magic cookie field has the correct  
> value, and that   the message length is sensible.  If the  
> FINGERPRINT extension   is being used, the agent checks that the  
> FINGERPRINT attribute is   present and contains the correct value.   
> If any of these conditions are not met, the message is silently  
> discarded or, in the case when STUN is being   multiplexed with  
> another protocol,  the agent should try to   parse the message as a  
> different protocol.
>
>>>>> What is a STUN server supposed to use as error code when an  
>>>>> unknown
>>>>> method is
>>>>> received? From the list in 3489bis, Section 15.6, I'd be tempted  
>>>>> to
>>>>> pick

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 25 Apr 2008 11:02:03 -0400

I don't know if you're looking for my own comments on my own  
suggestion, but regardless:

- I view not reporting some sort of error for an unknown method to be  
important enough that it needs to be fixed
- The rest I think is just a clarifying change to the text that's  
already there, which I think would be fine for author's 48.  The  
existing text mixes the issues of unknown method, dropping completed/ 
unknown transactions, and ignoring messages that don't appear to be  
stun into one paragraph that really doesn't specify what should be  
done and only gives hints that need to be interpreted and reordered  
in an implementation.

Bruce

On Apr 25, 2008, at 10:49 AM, Philip Matthews wrote:
> not add any new functionality, but just gives faster recovery from  
> an error case.
>
> PS. I agree that, _if_ we were to make this change, a new error  
> code would be appropriate.
> programming techniques should confirm that the method in the  
> response matches that in the request, even though the match on the  
> transaction id should guarantee this.
> PPPS. And I still wonder if there are not cases where we want a  
> silent drop, and not an error response.
>
>> first two   bits are 0, that the magic cookie field has the  
>> correct value, and that   the message length is sensible.  If the  
>> FINGERPRINT attribute is   present and contains the correct  
>> value.  If any of these conditions are not met, the message is  
>> silently discarded or, in the case when STUN is being    
>> multiplexed with another protocol,  the agent should try to    
>> agent checks that the transaction ID matches a   transaction that  
>> is still in progress.   If the transaction ID does not match an in- 
>> Then move the case of the unknown method check to 7.3.1 and return  
>> a 400 (actually, I think a new error response would be appropriate  
>> here).
>>
>> Actually, I think there's a bizarre pathological case here.  I  
>> don't see a specification that Is there a requirement anywhere in  
>> the protocol that the UAC must check that the method in a response  
>> matches the method in the request.  So possibly the above tid  
>> check should also check that the method matches the original request.
>>
>> Bruce
>>
>>
>>
>>>>>> received? From the list in 3489bis, Section 15.6, I'd be  
>>>>>> tempted to
>>>>>> pick
>>>>> the