Subject: [Sipping] New Draft on Reason Header in Responses

From: "Jesske, R" <[email-masked]>
Date: Thu, 21 Feb 2008 09:22:00 +0100

Dear all,
we would like to point you to a new draft we see the need for:
 
http://tools.ietf.org/wg/sipping/draft-jesske-sipping-etsi-ngn-reason-03.txt
 
The SIP procedures specified in this document are foreseen for 
   networks providing simulation services and/or interworking to the 
   PSTN/ISDN.   
   The document is describing the use of the Reason header in SIP 
   responses. These procedures are only valuable if the reason contained 
   in the element "protocol" is "Q.850". A inclusion of a SIP reason 
   (protocol="SIP") is not helpful due to the fact that the response 
   already provides the SIP reason. The Release Causes are described 
   within ETSI EN300 485 [5]  

I would be happy to get comments.
 
Thanks and Best Regards
 
Roland

Achtung ab 21.01.2007 neue Rufnummer +49 6151 628 2766

Deutsche Telekom AG 
Zentrum Technik Einführung 
Roland Jesske 
Gateways, Protokolle, Konvergenz, TE33-6 
Heinrich-Hertz-Str. 3-7,  64295 Darmstadt,  
Postfach, 64307 Darmstadt (Postanschrift) 
06151 628 2766 (Tel)
01718618445  (Mobile) 
E-Mail: [email-masked] 

 <http://www.telekom.de/> http://www.telekom.de 

Registerrechtliche Unternehmensangaben: 
Deutsche Telekom AG
Aufsichtsrat: Dr. Klaus Zumwinkel (Vorsitzender)
Vorstand: René Obermann (Vorsitzender), Dr. Karl-Gerhard Eick (stellvertretender Vorsit-zender), Hamid Akhavan, Reinhard Clemens, Timotheus Höttges, Thomas Sattelberger 

Handelsregister: Amtsgericht Bonn HRB 6794, 
Sitz der Gesellschaft: Bonn 
WEEE-Reg.-Nr.: DE50478376 
*************************************************************** 
Deutsche Telekom AG 
Supervisory Board: Dr. Klaus Zumwinkel (Chairman) 
Board of Management: René Obermann (Chairman), 
Dr. Karl-Gerhard Eick (Deputy Chairman), 
Hamid Akhavan, Reinhard Clemens, 
Timotheus Höttges,  Thomas Sattelberger 
Commercial register: Amtsgericht Bonn HRB 6794, 
corporate seat: Bonn 
WEEEreg.no: DE50478376 

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Thu, 21 Feb 2008 21:00:08 -0500

I take it that your proposal is to use the SIP Reason header to carry
the real ISUP cause value in failure responses that are gatewayed back
from the PSTN.  But I don't think that you state this directly
anywhere in the document, and the Abstract is especially obscure:

   This document proposes the use of the Reason header field in SIP 
   responses. 

Editorial questions aside, there seems to be some problem with the
security considerations:

7. Security Considerations  
  
   The presence of the Reason header in a response does not affect the  
   treatment of the response.  
   Including such a header by an untrusted entity could adulterate the  
   reactions of the originating entities. E.G. sending back a cause value  
   "87" can cause an announcement within the PSTN/ISDN saying that the  
   call was rejected due to the Closed User Group service.   
   Therefore it is RECOMMENDED to include the Reason header information 
   in Responses only by trusted entities as it is described within 
   RFC3325 [7]

Given this security goal, recommending that only trusted entities put
Reason headers in responses is pointless, as the Bad Guys will put
Reason headers in responses, too.  What you need is some way to
determine if the contents of a Reason header are to be trusted.

Dale

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 26 Feb 2008 07:48:14 +0100

Hi Dale,
Thank you for your comments. 

I added some text in the overview section as follows.

The main used case for reason header within responses are interworking situations with PSTN/ISDN networks where the ISUP cause In many cases the mapping of specific cause values will result in a generic SIP Response like it is shown below.

I hope this will make the main use clear.

With regard to the Security considerations the idea behind was, if you don't trust the regarding UA sending such reason a Application server will delete the cause value. As it is for the P-Preferred-Identity.
Nevertheless within the PSTN it is also allowed that end devices will release the call and send a cause value with. So there is the same problem.
On other question is what the bad guy will reach. The only is that the other side will perhaps get a wrong cause or an wrong announcement. So the bad guy will harm himself.

Or do you have any other in mind?

Thanks and Best Regards

Roland 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Freitag, 22. Februar 2008 03:00
> An: [email-masked]
> Betreff: Re: [Sipping] New Draft on Reason Header in Responses
> 
> 
>