Subject: [Sipping] I-D ACTION:draft-ietf-sipping-sipt-04.txt

From: [email-masked]
Date: Sun, 07 Jul 2002 12:33:05 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: SIP for Telephones (SIP-T): Context and Architectures
	Author(s)	: A. Vemuri, J. Peterson
	Filename	: draft-ietf-sipping-sipt-04.txt
	Pages		: 32
	Date		: 05-Jul-02
	
The popularity of gateways that interwork between the PSTN (Public
Switched Telephone Network) and SIP networks has motivated the
publication of a set ofcommon practices that can assure consistent
behavior across implementations.  This document taxonomizes the uses
of PSTN-SIP gateways, provides uses  cases, and identifies mechanisms
necessary for interworking.  The mechanisms detail how SIP provides
for both 'encapsulation' (carriage of PSTN signaling across a SIP
network) and 'translation' (protocol mapping).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-sipt-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-sipt-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 12 Jul 2002 12:07:34 +0100

All,

As an aside to the security issue, there is an issue with respect to ISUP
compatibility which is not addressed by the use of S/MIME.

ISUP may carry information which is marked as 'essential' for the call to
continue according to the compatibility mechanism. If this information
cannot be propogated to a point where it is understood, then the call MUST
be released. Therefore handling of such ISUP bodies is mandatory
('handling=required' in the Content-Disposition).

In these cases, the message can only be sent if it is known that the
downstream nodes correctly act on the Content-Disposition header. S/MIME
will not help us here - the receiving node needs to be known to the sending
node a priori, and known to behave in this way (and authenticated) i.e. we
are in Trust Domain territory.

Does anyone feel this needs clarification ? My concern is that people may
mistakenly believe that S/MIME encryption/integrity makes it safe to send
ISUP bodies in all cases, whereas this is only the case if
'handling=optional'.

Regards,

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 07 July 2002 17:33
> Cc: [email-masked]
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-sipt-04.txt
> 
>

---

From: "Kevin Summers" <[email-masked]>
Date: Fri, 12 Jul 2002 09:03:19 -0500

I agree. This needs to be clarified in the draft.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, July 12, 2002 6:08 AM
To: [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-sipt-04.txt

All, 

As an aside to the security issue, there is an issue with respect to
ISUP compatibility which is not addressed by the use of S/MIME.

ISUP may carry information which is marked as 'essential' for the call
to continue according to the compatibility mechanism. If this
information cannot be propogated to a point where it is understood, then
the call MUST be released. Therefore handling of such ISUP bodies is
mandatory ('handling=required' in the Content-Disposition).

In these cases, the message can only be sent if it is known that the
downstream nodes correctly act on the Content-Disposition header. S/MIME
will not help us here - the receiving node needs to be known to the
sending node a priori, and known to behave in this way (and
authenticated) i.e. we are in Trust Domain territory.

Does anyone feel this needs clarification ? My concern is that people
may mistakenly believe that S/MIME encryption/integrity makes it safe to
send ISUP bodies in all cases, whereas this is only the case if
'handling=optional'.

Regards, 

Mark 

> From: [email-masked] [ mailto:[email-masked]] 
> Sent: 07 July 2002 17:33 
> Cc: [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 13 Jul 2002 19:25:54 -0500

Support for Content-Disposition 'handling' parameter is now specified in
RFC3261 - it is not predicated on supporting any ISUP MIME bodies (although
the fact that the parameter happens to be defined in RFC3204 has admittedly
been a source consternation to some, especially outside the SIP community).
In fact, RFC3204 defines the parameter only because it happened to pass
before RFC3261 - originally, RFC2543bis defined the parameter and the
isup-mime Internet-Draft referenced it in bis, but the definition was moved
to RFC3204 in order to get the document through the IESG.
 
So, I don't think we need to import the concept of Trust Domains to SIP-T in
order to guarantee that the Content-Disposition 'handling' parameter will be
understood. This is no more unsafe than relying on remote endpoints to
support any other statute of RFC3261.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, July 12, 2002 8:08 PM
To: [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-sipt-04.txt

All, 

Regards, 

Mark 

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-04.txt
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-sipt-04.txt>  
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 15 Jul 2002 10:26:29 +0100

Jon wrote:

"So, I don't think we need to import the concept of Trust Domains to SIP-T
in order to guarantee that the Content-Disposition 'handling' parameter will
be understood. This is no more unsafe than relying on remote endpoints to
support any other statute of RFC3261."

True, but relying on the written words of any statute to prevent fraud is no
protection at all. We can rely on a remote endpoint to support RFC3261 *when
it is in that endpoints own interest to do so*, but not otherwise.

Either you *know* a priori that the 'next node' supports certain procedures,
or you don't - it doesn't matter what specification they are defined in. If
someone can gain some financial advantage by not supporting some particular
procedure, then it is unwise to rely on that procedure being mandatory in
some spec.

If the ISUP message contains some 'essential' information, this may be
because some service is operating which results in a different charge for
the call, and the call should not continue at all if that service cannot be
provided.

Therefore, we must have a priori knowledge that the next node not only
supports 'handling' as per RFC3261, but that it knows that ISUP MIME bodies
cannot be passed to nodes which do not also have these properties - at least
this is the case if handling=required.

Regards...Mark

_______________________________________________
Sipping mailing list  https://www1.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: "Peterson, Jon" <[email-masked]>
Date: Mon, 15 Jul 2002 06:55:03 -0500

I'm not sure that I understand what fraud is likely to be perpetrated when a
recipient of a SIP-T request is unwilling or unable to decipher encapsulated
ISUP - can you substantiate that a bit? 

We'd probably both agree that whether or not a recipient is known to
implement 'handling=required' as a protocol mechanism, a malevolent
recipient could conveniently neglect to process the ISUP body (in whole or
in part), so I'm not sure that merely assuring protocol compliance with the
Content-Disposition mechanism could ever be sufficient to allay any such
concerns.

SIP-T is, unlike some similar initiatives, predicated on the notion that
telephone calls can land on devices other than PSTN gateways - encryption
can be leveraged to assure that ISUP cannot be inspected by inappropriate
destinations, but as you surmise SIP-T's security has not been tooled to any
threat that results from the intentional failure to process ISUP messages.

Your pattern of inference below could be re-used to argue that SIP itself
could never be used for a commercial service without a trust domain. If that
is your inevitable implication, then surely this problem isn't specific to
SIP-T, anyway, and it's no particular incentive to add text to the SIP-T
framework. 

Jon Peterson
NeuStar, Inc.

> Sent: Monday, July 15, 2002 6:26 PM
> To: 'Peterson, Jon'; [email-masked]

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 15 Jul 2002 13:50:19 +0100

Jon,

See notes below...

> ISUP - can you substantiate that a bit? 

Suppose I have some kind of Closed User Group service where calls to
destinations within the CUG are free and calls outside the CUG are not
allowed. Suppose this operates by including a CUG code in the IAM and
marking this as 'required'. The originating exchange assumes that if the
call is routed anywhere that involves the CUG code being dropped, then the
whole call will be dropped.

If the call is routed somewhere which understands the CUG code, this
exchange either connects or rejects the call based on whether the actual
destination is in the CUG or not.

If the CUG code is just discarded, the call could be connected in error.

Ok, so standardised ISDN CUG does not rely on the compatibility mechanism in
this way, but the point about the ISUP compatibility mechanism is it
provides information about otherwise unrecognised parameters. If we have an
'essential' parameter we do not know what it is for, but we do know that it
is sufficiently important that the originating operator would rather *forego
the revenue* from the call than have this parameter discarded.

> Content-Disposition mechanism could ever be sufficient to 

I would envisage 'handling=required' ISUP bodies only ever being passed to
proxies which are known to follow the necessary procedures because they are
owned by the same operator, or by a partner with whom appropriate agreements
have been made. Same as knowing that the next node supports
Asserted-Identity procedures.

If routing logic indicates that the call should go anywhere else, I would
reject it there and then.

> telephone calls can land on devices other than PSTN gateways

In general, yes, but this cannot apply to 'handling=required' ISUP (modulo
devices which understand ISUP but which are not 'PSTN gateways' if such
exist.)

> - encryption
> could never be used for a commercial service without a trust 
> domain. 

I don't think the argument applies in the same way. When I send a SIP
message to a previously unknown proxy, whose address I have discovered
through DNS, then of course I know nothing about whether it is compliant to
SIP. But I am not risking anything by sending the message. If it turns out
that the other proxy is non-compliant, and the service fails, then this is
just bad luck for the customer of this other proxy (and bad luck for the
proxy owner).

The system works because everyone acts in their own interest. The effect of
non-compliances is just failed calls, so everyone has an incentive to be
complient. In the handling=required ISUP case, the consequence of
non-compliance could be calls completed in error, which is a whole different
story.

If I understand correctly, SIP does not make hard assumptions about
compliance of correspondant devices - at least this is what I thought the
whole Asserted-Identity debate was about - the very reason I need the Trust
Domain is that I can't trust any random proxy to obey things like
Proxy-Require headers etc.

ISUP *does* make hard assumptions about compliance of other devices.
Fortunately, the ISUP compatibility mechanism tells us exactly when these
assumptions are important in terms of information being ignored.

...Mark

> If that